Re: lockdep null-ptr-deref

2020-10-02 Thread Qian Cai
On Fri, 2020-10-02 at 12:06 +0200, Peter Zijlstra wrote: > On Wed, Sep 30, 2020 at 11:49:37AM +0200, Peter Zijlstra wrote: > > On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote: > > > On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote: > > > > I think there are two problems her

Re: lockdep null-ptr-deref

2020-10-02 Thread Boqun Feng
On Fri, Oct 02, 2020 at 03:09:29PM +0200, Peter Zijlstra wrote: > On Fri, Oct 02, 2020 at 08:36:02PM +0800, Boqun Feng wrote: > > > But what if f2() is called with interrupt disabled? Or f2() disables > > interrupt inside the function, like: > > > > void f2(...) > > { > > loca

Re: lockdep null-ptr-deref

2020-10-02 Thread Peter Zijlstra
On Fri, Oct 02, 2020 at 08:36:02PM +0800, Boqun Feng wrote: > But what if f2() is called with interrupt disabled? Or f2() disables > interrupt inside the function, like: > > void f2(...) > { > local_irq_disable(); > spin_lock(&B); > g(...); >

Re: lockdep null-ptr-deref

2020-10-02 Thread Boqun Feng
On Wed, Sep 30, 2020 at 09:02:28PM +0200, Peter Zijlstra wrote: > On Wed, Sep 30, 2020 at 08:18:18PM +0800, Boqun Feng wrote: > > > For one thing, I do think that LOCK_READ_USED trace is helpful for > > better reporting, because if there is a read lock in the dependency path > > which causes the d

Re: lockdep null-ptr-deref

2020-10-02 Thread Peter Zijlstra
On Wed, Sep 30, 2020 at 11:49:37AM +0200, Peter Zijlstra wrote: > On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote: > > On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote: > > > I think there are two problems here: > > > > > > 1) the "(null)" means we don't have the "usage_st

Re: lockdep null-ptr-deref

2020-09-30 Thread Peter Zijlstra
On Wed, Sep 30, 2020 at 08:18:18PM +0800, Boqun Feng wrote: > For one thing, I do think that LOCK_READ_USED trace is helpful for > better reporting, because if there is a read lock in the dependency path > which causes the deadlock, it's better to have the LOCK_READ_USED trace > to know at least t

Re: lockdep null-ptr-deref

2020-09-30 Thread Boqun Feng
On Wed, Sep 30, 2020 at 11:49:37AM +0200, Peter Zijlstra wrote: > On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote: > > On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote: > > > I think there are two problems here: > > > > > > 1) the "(null)" means we don't have the "usage_st

Re: lockdep null-ptr-deref

2020-09-30 Thread Peter Zijlstra
On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote: > On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote: > > I think there are two problems here: > > > > 1) the "(null)" means we don't have the "usage_str" for a usage bit, > > which I think is the LOCK_USED_READ bit introduced

Re: lockdep null-ptr-deref

2020-09-30 Thread Peter Zijlstra
On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote: > I think there are two problems here: > > 1) the "(null)" means we don't have the "usage_str" for a usage bit, > which I think is the LOCK_USED_READ bit introduced by Peter at > 23870f122768 ('locking/lockdep: Fix "USED" <- "IN-NMI" inve

Re: lockdep null-ptr-deref

2020-09-29 Thread Boqun Feng
On Tue, Sep 29, 2020 at 10:31:56AM -0400, Qian Cai wrote: > I tried to add a few new Kconfig options like LEDS_TRIGGERS instantly trigger > a > warning during the boot, and then there is null-ptr-deref in lockdep below. > Any > idea? > > [ 16.487309] WARNING: possible irq lock inversion depend