Re: [PATCH v2 2/6] locking/lockdep: Throw away all lock chains with zapped class

[Waiman Long]

On 1/13/20 11:05 AM, Bart Van Assche wrote:
> On 1/13/20 7:18 AM, Peter Zijlstra wrote:
>> On Mon, Dec 16, 2019 at 10:15:13AM -0500, Waiman Long wrote:
>>> If a lock chain contains a class that is zapped, the whole lock
>>> chain is
>>> now invalid.
>>
>> Possibly. But I'm thinking that argument can/should be made mode
>> elaborate.
>>
>> Suppose we have A->B->C, and we're about to remove B.
>>
>> Now, I suppose the trivial argument goes that if we remove the text that
>> causes A->B, then so B->C will no longer happen. However, that doesn't
>> mean A->C won't still occur.
>>
>> OTOH, we might already have A->C and so our resulting chain would be a
>> duplicate. Conversely, if we didn't already have A->C and it does indeed
>> still occur (say it was omitted due to the redundant logic), then we
>> will create this dependency the next time we'll encounter it.
>>
>> Bart, do you see a problem with this reasoning?
>>
>> In short, yes, I think you're right and we can remove the whole thing.
>> But please, expand the Changelog a bit, possibly add some of this
>> reasoning into a comment.
>
> I think unconditionally dropping lock chains is wrong. If a lock class
> is zapped the rest of the lock chain remains valid and hence should be
> retained unless it duplicates another lock chain or if the length of
> the lock chain is reduced to a single element. 

If the zapped class is at the end of the chain, the shorten one without
the zapped class should have been stored already as the current code
will store all its predecessor chains. If it is somewhere in the middle,
there is no guarantee that the partial chain will actually happen. It
may just clutter up the hash and make searching slower. Why don't we
just store it when it actually happens?

Cheers,
Longman