Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1641892yba; Tue, 2 Apr 2019 12:51:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOnzSBbOAviYUNdVfn+x5W/Bg00i876jGgBXMQr/MsJexdQ4U3CToXM3MUo90UahYqgmVq X-Received: by 2002:a62:a509:: with SMTP id v9mr72459114pfm.64.1554234679286; Tue, 02 Apr 2019 12:51:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554234679; cv=none; d=google.com; s=arc-20160816; b=KSRahLVTuvf8HNdGcCeHJJYDuSB7xO0HZW9tzNOXNNjgLwndoTb2xbamidMjQA+pvS z38UW2f36v0SlI7EO8uYH4Gjd0u56QWhQseln8zAU+uHJk6iuOZbzfmw/oxN4b7hJxz3 6scEBEFQ1FdAPjSjE62+vhiZXOUkqa9L1sdpMmL8DwHMDGaCgaXc4q6LRV3tx5RhAn55 d4X/tWhtpGRPuvu1NqHqVh9xfdEYxflqKHf9PI/imcwNKx5FUkLQLfrPhg/10R5IuyL3 Y4e9irm+QMYpmF8jD813If0sC82sHCVqyr9fnX3p3j/pVn0tIb1+XhslgHjgt9Wt+Q4v ARzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature; bh=VfV6qEx4GfxVkCo7NG9vbB5klK2CoGPcrGR89KYgSN8=; b=OsCljDB/bvdbxR+nX9yMF6qtyYao0AHeiPRKwYQhoUFY0UClk5KOecwpAqcUr2GnQ8 lRn6+U1gbxtUvBXxU0w21DSIeaGvleAQDjbkcmmC7HsadW0C5OSbwAdQfwL3DVO8PDVQ orSxnZwgfGNfJ9vAhqFlExo+ZXfQ2S1UIkjYubB9wzAja150qqtvneLeN2LGvD43/tf+ 0M9ysJVHmu9BbouV3CwMEqtS83jbrR0QnmaWMPxCg0d9Sc2cLbWU1y4DW8O9NXbdRUWg yvc0r5qXSgGap1H4M9FAjGxYwIi6/bTYxZeE0JU5KT2Osvk2QIJkyRt+E8IPaHDJ8Z71 qWwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm2 header.b=uvmgAgam; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=SWhPEyW2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w17si11922964pll.30.2019.04.02.12.51.04; Tue, 02 Apr 2019 12:51:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm2 header.b=uvmgAgam; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=SWhPEyW2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730780AbfDBTZ4 (ORCPT + 99 others); Tue, 2 Apr 2019 15:25:56 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33773 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbfDBTZz (ORCPT ); Tue, 2 Apr 2019 15:25:55 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 178512204C; Tue, 2 Apr 2019 15:25:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 02 Apr 2019 15:25:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tobin.cc; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=VfV6qEx4GfxVkCo7NG9vbB5klK2 CoGPcrGR89KYgSN8=; b=uvmgAgamqYQxUyvgTEGeOmMVBfFOxyKaVYlilZPReZe OmWFEhyLNXSmBH47sqeiOF4TFeQmH0IWtHOeF4DZuzus8KoNXkI00Uyti2YfhR5b z5QgKz9MVh+DGyTfh4QpasTgYo/ovq0XJU/MXSNwzOYb7e5jRq6njH7f0+v69+oq 2Jz+EgE1pqUSns0eMS9ZM0C+EgekxlWSdQ4NIE07l0SHmgu5qYQHltE7/qmXG/sT xCABypGyj92UcO6oksXnoNMX6xCrVdHIs9LOdOGXj25ivlemqSna+M2jKurs6h6K Nrrst6ze6/ivhJZCdLwE6mWw7HOAwt9fHtJViY8DiHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=VfV6qE x4GfxVkCo7NG9vbB5klK2CoGPcrGR89KYgSN8=; b=SWhPEyW2dP94KixYJL0MEp a4vp25kAz3goJDtnZuGdTiUs2NCrfGNv4cRmRaFI53AeIX/VlnlHiY3ajjQ1qsYz ir4HPETq/h5qUjQSiCQ6KUA5FotbSK4xmuT8Vezqf7pyPk9nNtc5/5J9icpfNypn Ct/pknguD8rrmtvf39X3StsWtAoDgBl7RnSZIJGiioNl3UoKING0z2VWi/OfWFHP WjMy5PEbCuvTf+4PTQHu7AUSRpDQV/RFfjKQMyqgbYvXWpoLFxU1Nw4ubP/oDOCf 7GDIQj4YBRIkk07IxLVqh7FAvs39ffGpmBsxLD/hEliau0nOnjJEXMe4jTMSatdQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtddtgdduudeiucdltddurdeguddtrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnegfrhhlucfvnfffucdludehmdenucfjughrpeffhffvuffk fhggtggujgfofgesthdtredtofervdenucfhrhhomhepfdfvohgsihhnucevrdcujfgrrh guihhnghdfuceomhgvsehtohgsihhnrdgttgeqnecukfhppeduvdegrdduieelrddvjedr vddtkeenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsehtohgsihhnrdgttgenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (124-169-27-208.dyn.iinet.net.au [124.169.27.208]) by mail.messagingengine.com (Postfix) with ESMTPA id 99E1310395; Tue, 2 Apr 2019 15:25:53 -0400 (EDT) Date: Wed, 3 Apr 2019 06:25:20 +1100 From: "Tobin C. Harding" To: Al Viro Cc: Jonathan Corbet , "Tobin C. Harding" , Mauro Carvalho Chehab , Neil Brown , Randy Dunlap , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 00/24] Convert vfs.txt to vfs.rst Message-ID: <20190402192520.GA6285@eros.localdomain> References: <20190327051717.23225-1-tobin@kernel.org> <20190402094934.5b242dc0@lwn.net> <20190402164824.GK2217@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190402164824.GK2217@ZenIV.linux.org.uk> X-Mailer: Mutt 1.11.4 (2019-03-13) User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 02, 2019 at 05:48:24PM +0100, Al Viro wrote: > On Tue, Apr 02, 2019 at 09:49:34AM -0600, Jonathan Corbet wrote: > > On Wed, 27 Mar 2019 16:16:53 +1100 > > "Tobin C. Harding" wrote: > > > > > Hi Al, > > > > > > This series converts the VFS file Documentation/filesystems/vfs.txt to > > > reStructuredText format. Please consider taking this series through > > > your tree as apposed to Jon's tree because this set makes a fair amount > > > of changes to VFS files (and also the VFS tree and docs tree are out of > > > sync right now with the recent work by Mauro and Neil). > > > > Al, do you have any thoughts on how you want to handle this? I was about > > to apply Jeff Layton's vfs.txt update, but would rather not create > > conflicts unnecessarily. Let me know if you'd like me to pick this work > > up. > > Frankly, I would rather see that file be eventually replaced by something > saner, and I'm not talking about the format. Are you able to extrapolate on this comment please? Is this something someone new to the VFS (me) can do with a little nudge in the right direction or is this something that needs thorough knowledge of the VFS? > Re Jeff's patch... > > + d_prune: called prior to pruning (i.e. unhashing and killing) a hashed > + dentry from the dcache. > > is flat-out misguiding. First of all, it *is* called for unhashed dentries, > TYVM. Furthermore, "prior to" is far too vague. This patch includes documentation for d_prune() very similar to Jeff's patch (taken from a comment somewhere in filesystems code IIRC). I can have a go at working all the comments below into better documentation if that is useful (dependant on answer to question above). thanks, Tobin. (leaving text below for reference) > What really happens: there's a point in state diagram for dentries where > we commit to destroying a dentry and start taking it apart. That transition > happens with ->d_lock of dentry, ->i_lock of its inode (if any) and > ->d_lock of the parent (again, if any) held; ->d_prune() is the last > chance for filesystem to see the (now doomed) dentry still intact. > > It doesn't matter whether it's hashed or not, etc. The locks held > are sufficient to stabilize pretty much everything[1] in dentry and > nothing is destroyed yet. The only apparent exception is ->d_count, > but that's not real - we are guaranteed that there had been no other > counted references to dentry at the decision point and that none > could've been added. So this "oh, it's not 0 now, it's gone negative > after lockref_mark_dead() the caller has just done" is a red herring. > > ->d_prune() must not drop/regain any of the locks held by caller. > It must _not_ free anything attached to dentry - that belongs > later in the shutdown sequence. If anything, I'm tempted to > make it take const struct dentry * as argument, just to make > that clear. > > No new (counted) references can be acquired by that point; > lockless dcache lookup might find our dentry a match, but > result of such lookup is not going to be legitimized - it's > doomed to be thrown out as stale. > > It really makes more sense as part of struct dentry lifecycle > description... > > [1] in theory, ->d_time might be changed by overlapping lockless > call of ->d_revalidate(). Up to filesystem - VFS doesn't touch > that field (and AFAICS only NFS uses it these days).