Messages in this thread | | | Date | Wed, 30 Sep 2020 11:16:10 +0200 | From | Peter Zijlstra <> | Subject | Re: lockdep null-ptr-deref |
| |
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" inversions'). > > 2) the next null-ptr-deref, and I think this is also caused by > LOCK_USED_READ bit, because in the loop inside > print_lock_class_header(), we iterate from 0 to LOCK_USAGE_STATES (which > is 4*2 + 3), however the class->usage_traces[] only has > XXX_LOCK_USAGE_STATES (which is 4*2 + 1) elements, so if we have > LOCK_USED_READ bit set in ->usage_mask, we will try to access an element > out of the ->usage_traces[] array. > > Probably the following helps? And another possible fix is to enlarge the > ->usage_trace[] array and record the call trace of LOCK_READ_USED.
Urgh.. yeah, I wanted to avoid saving that trace; it's pretty useless :/ The existing USED trace is already mostly pointless, the consistent thing would be to remove both but that might be too radical.
But you're right in that I made a right mess of it. Not sure what's best here.
Let me have a play.
| |