Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753391AbaFCKz7 (ORCPT ); Tue, 3 Jun 2014 06:55:59 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:53418 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751201AbaFCKz5 (ORCPT ); Tue, 3 Jun 2014 06:55:57 -0400 Date: Tue, 3 Jun 2014 12:55:47 +0200 From: Peter Zijlstra To: John Stultz Cc: Trond Myklebust , Jeff Layton , Linus Torvalds , Linux NFS Mailing List , Linux Kernel mailing list , Ingo Molnar Subject: Re: nfs4_do_reclaim lockdep pop in v3.15.0-rc1 Message-ID: <20140603105547.GV11096@twins.programming.kicks-ass.net> References: <20140602104948.4faf0bc2@tlielax.poochiereds.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g4y/k9+5pukpRNAq" Content-Disposition: inline In-Reply-To: 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 --g4y/k9+5pukpRNAq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 02, 2014 at 08:19:00PM -0700, John Stultz wrote: > On Mon, Jun 2, 2014 at 5:59 PM, Trond Myklebust > wrote: > > On Mon, Jun 2, 2014 at 6:49 PM, John Stultz wr= ote: > >> On Mon, Jun 2, 2014 at 3:42 PM, Trond Myklebust > >> wrote: > >>> The so_reclaim_seqcount only exists in order to tell the other threads > >>> that they may need to replay file open or file lock requests that have > >>> raced with state recovery (because those threads got scheduled out > >>> after their RPC calls ran, but before they managed to set up the > >>> tracking of the new state). It is basically an edge condition > >>> killer... > >> > >> Would then swapping the acquisition order, so the seqcount is taken > >> before the so_lock at the top of nfs4_reclaim_open_state() avoid this > >> then, without having to disable lockdep? > >> > > > > I can change the write seqcount to use raw_write_seqcount(), but that >=20 > So this doesn't address my suggestion to change the locking order... > is that solution not feasible? >=20 > > doesn't answer the question of why raw_seqcount_begin() is the _only_ > > object out there with a "raw_" prefix, that doesn't explicitly disable > > lockdep checking. > > > > What justifies the inconsistency? >=20 > Here's the naming discussion... > https://lkml.org/lkml/2014/1/2/404 >=20 Ah, I think I see what Trond means; so raw_write_seqcount_{begin,end}() are without lockdep, _however_ raw_seqcount_begin() is with lockdep. This is inconsistent within the same API (seqcount/seqlock). Yes, we should fix that. raw_seqcount_begin() is a variant of read_seqcount_begin() but without the spin loop in. Maybe we should find a new name for this. --g4y/k9+5pukpRNAq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJTjamzAAoJEHZH4aRLwOS69AUP/jEQuHc5R0qDHtIC4w0ddCBj rWuoZpa/coiLxw632iyGo7HWgLfyvyi1uJOxvRf+l5aX8ZuYJAK3F5fnf06G0Hgo q1ezg2KzGNO6li8HXOcHM7ezSOKQXEAr/rZNmeFuNiBDdQVsLWzRwEuck/E1M9bE SsBNboXXaQ55U7PBNHqpYCVaMnz6lfYZ6I5Wd6KbaeIbw2bhOL/g/d6jHuGYpm9g nRQQL1phBL8n7GtahtEe3DlOhVUk5C8B4Ct0Icbc1qGXFeiHMwE9EQ7aEzQgo7EQ VD05q9w5KqF8eqXxgHfX2N5jk/jDak3pAoeWL/rFNmPC2OFEyJFEuxLR0N56+rnY pH2agfeTtfcnRoSveyLn7JcVrx+kMgV/F/nnOXeJ+1Co/zFDumDbmikpkDnMviaQ 2RkO4DoczMMIeL/IdR3h5dQ5v2iL608Y9eCDXISWgiIDRIyo2N9cDmPCcBsVcgp1 IsAIZ5LWgA24cT54ZriHXmkgVsXFL6GN9xFd3Wn5JDLrzByPYMDS1YTj/apCAtWO YV6RZDkwFMfvQWz6xJmqWv2RZ0xGceNtlKVOdEEqKwQ5PR5rAUIuVLxEXVZCBcuT JEDF7r+4Fv9oM9i6YrOcDqlSnEQiHDjypVnaBAyY7Pgvy7tBn54jaxiOkwd29TgI fAL6Vq5TUMZSW3XMQSIn =no82 -----END PGP SIGNATURE----- --g4y/k9+5pukpRNAq-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/