On Sat, May 30, 2020 at 12:25:05AM +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2020 at 06:14:01PM -0400, Steven Rostedt wrote:
> > Why remove the check for debug_locks? Isn't that there to disable
> > everything at once to prevent more warnings to be printed?
>
> Yeah, maybe. I was thinking we
On Sat, May 30, 2020 at 12:25:05AM +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2020 at 06:14:01PM -0400, Steven Rostedt wrote:
> > On Fri, 29 May 2020 23:27:41 +0200
> > Peter Zijlstra wrote:
> >
> > > There is no reason not to always, accurately, track IRQ state.
> > >
> > > This change also
On Sat, 30 May 2020 00:25:05 +0200
Peter Zijlstra wrote:
> > > + if (DEBUG_LOCKS_WARN_ON(current->lockdep_recursion &
> > > LOCKDEP_RECURSION_MASK))
> > > return;
>
> ^^ there's your regular recursion check.
Yes, but this is more of a "bug if it happens" than just "ignore it".
--
On Fri, May 29, 2020 at 06:14:01PM -0400, Steven Rostedt wrote:
> On Fri, 29 May 2020 23:27:41 +0200
> Peter Zijlstra wrote:
>
> > There is no reason not to always, accurately, track IRQ state.
> >
> > This change also makes IRQ state tracking ignore lockdep_off().
> >
> > Signed-off-by: Peter
On Fri, 29 May 2020 23:27:41 +0200
Peter Zijlstra wrote:
> There is no reason not to always, accurately, track IRQ state.
>
> This change also makes IRQ state tracking ignore lockdep_off().
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/locking/lockdep.c | 33 +
There is no reason not to always, accurately, track IRQ state.
This change also makes IRQ state tracking ignore lockdep_off().
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/locking/lockdep.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
--- a/ker
6 matches
Mail list logo
