linux-kernel - Re: + shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch added to -mm tree

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] [day] [month] [year] [list]

Message-ID: <20140714101007.GR9918@twins.programming.kicks-ass.net>
Date:	Mon, 14 Jul 2014 12:10:07 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Vlastimil Babka <vbabka@...e.cz>, akpm@...ux-foundation.org,
	davej@...hat.com, koct9i@...il.com, lczerner@...hat.com,
	stable@...r.kernel.org, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: + shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch
 added to -mm tree

On Sun, Jul 13, 2014 at 05:43:13PM -0400, Sasha Levin wrote:
> On 07/11/2014 11:59 AM, Peter Zijlstra wrote:
> >>> I agree with you that "The call trace is very clear on it that its not", but
> >>> > > when you have 500 call traces you really want something better than going
> >>> > > through it one call trace at a time.
> >> > 
> >> > Points well made, and I strongly agree with Vlastimil and Sasha.
> >> > There is a world of difference between a lock wanted and a lock held,
> >> > and for the display of locks "held" to conceal that difference is unhelpful.
> >> > It just needs one greppable word to distinguish the cases.
> > So for the actual locking scenario it doesn't make a difference one way
> > or another. These threads all can/could/will acquire the lock
> > (eventually), so all their locking chains should be considered.
> 
> I think that the difference here is that we're not actually debugging a locking
> issue, we're merely using lockdep to help with figuring out a non-locking
> related bug and finding it difficult because lockdep's list of "held locks"
> is really a lie :)

OK, so I suppose we could document that the top lock might not actually
be held (yet). But then who will ever read said document ;-)

The problem with 'fixing' this is that we don't exactly have spare
storage in struct held_lock, and lock_acquired() is only enabled for
CONFIG_LOCK_STAT.

I just don't think its worth it.

Content of type "application/pgp-signature" skipped