From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754921AbaGNKKh (ORCPT ); Mon, 14 Jul 2014 06:10:37 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:57638 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754584AbaGNKKZ (ORCPT ); Mon, 14 Jul 2014 06:10:25 -0400 Date: Mon, 14 Jul 2014 12:10:07 +0200 From: Peter Zijlstra To: Sasha Levin Cc: Hugh Dickins , Heiko Carstens , Vlastimil Babka , akpm@linux-foundation.org, davej@redhat.com, koct9i@gmail.com, lczerner@redhat.com, stable@vger.kernel.org, "linux-mm@kvack.org" , LKML Subject: Re: + shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch added to -mm tree Message-ID: <20140714101007.GR9918@twins.programming.kicks-ass.net> References: <53BECBA4.3010508@oracle.com> <53BED7F6.4090502@oracle.com> <53BEE345.4090203@oracle.com> <20140711082500.GB20603@laptop.programming.kicks-ass.net> <53BFD708.1040305@oracle.com> <20140711155958.GR20603@laptop.programming.kicks-ass.net> <53C2FD71.7090102@oracle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XG0jWBK27HhJN4nS" Content-Disposition: inline In-Reply-To: <53C2FD71.7090102@oracle.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --XG0jWBK27HhJN4nS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 no= t", but > >>> > > when you have 500 call traces you really want something better th= an going > >>> > > through it one call trace at a time. > >> >=20 > >> > 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 un= helpful. > >> > 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. >=20 > I think that the difference here is that we're not actually debugging a l= ocking > 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 lock= s" > 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. --XG0jWBK27HhJN4nS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJTw6x/AAoJEHZH4aRLwOS6CYUQAIW8h8abNG2/pBv2zXprnqX9 pXhRM+8UOsRQnVkUEurpx6Ga5FjZWSYNDXovIwlFvDYvLkl6AKefC5N3WG7Ck3vb Piklhx1Oe/vF9XN8dfSgm2v4eXYFagEU9rT6T4yWC3hm9L3aafwNxtfg9zeTt753 dxWO5nXRvJRXNn7sUW1XZzDU7QKIFeTA6F761HQToe7yrf+67ytTTGQw2asiQYdb xqnMMV9dcYPuVDIiIy6TnMHNYhez97mkwimysIMW0lpaKD39KrIxUFzN3NR//VLB NfwbyhBpDvndY1gYzfMYAynONTBl8Pw+dLb4rrGWYQlIQm3+L/wOPVCTWYbmIIeq Q1gfQTjR4etFqR8mrGsK4ouuFB5Ecbph8LzHOSY87jt8R6gTNFtqLcSDdTMlHHcJ n3L2i2FwQIcTp9rPjGkqAVz+pl9VIzYH49qxOWkawedn0uJwBJ91sejFeIOlKzqy FOK6XWANdg0TlEdURzXIZMP0d0jpNihOc36ddo+xYXK6gYUBGPW8bXtGTF1ckEe0 ofh6ubNZ20Cp3uN/9jbUWc5Jk+hqseVvLt9l0eFpoLeQsXs40hlGLxez7+3onD0V uBtHn31EKP1sCW+QgBNB0/Stzz+4WsvJZ1VQfI26tOmfrI5/92cam8q3cJnV7pI/ ueX3xqERq5Md3ek6lgz1 =FjA0 -----END PGP SIGNATURE----- --XG0jWBK27HhJN4nS--