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

Message-ID: <20140711155958.GR20603@laptop.programming.kicks-ass.net>
Date:	Fri, 11 Jul 2014 17:59:58 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Sasha Levin <sasha.levin@...cle.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 Fri, Jul 11, 2014 at 07:55:50AM -0700, Hugh Dickins wrote:
> On Fri, 11 Jul 2014, Sasha Levin wrote:
> > 
> > There's no easy way to see whether a given task is actually holding a lock or
> > is just blocking on it without going through all those tasks one by one and
> > looking at their trace.
> > 
> > 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 realize that 500+ single lock 'chains' can be tedious, otoh they're
easy to dismiss, since singe lock 'chains' are trivial and usually not
interesting in their own right.

> (Though I didn't find "The call trace is very clear on it that its not",
> I thought it too was telling me that the lock was already held somehow.)

The trace is in the middle of the mutex op, if it were really fully
acquired it would not be, it would be doing something else -- while
holding the mutex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/