lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bf44cb0-81fa-1056-0158-7c14ee424044@acm.org>
Date:   Mon, 13 Jan 2020 08:05:24 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Peter Zijlstra <peterz@...radead.org>,
        Waiman Long <longman@...hat.com>
Cc:     Ingo Molnar <mingo@...hat.com>, Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/6] locking/lockdep: Throw away all lock chains with
 zapped class

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.

Bart.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ