From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [git pull] more vfs bits Date: Sun, 22 Feb 2015 01:32:28 +0000 Message-ID: <20150222013228.GZ29656@ZenIV.linux.org.uk> References: <20150221033452.GU29656@ZenIV.linux.org.uk> <8417.1424564313@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Howells , Linux Kernel Mailing List , linux-fsdevel To: Linus Torvalds Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:36183 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751656AbbBVBcb (ORCPT ); Sat, 21 Feb 2015 20:32:31 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Feb 21, 2015 at 05:14:37PM -0800, Linus Torvalds wrote: > .. and this is the one that makes no sense to me. > > It's the common case, and I don't see how it *possibly* adds any > value. The "I want the inode of this dentry" is traditionally done as > "dentry->d_inode". > > What is the *upside* of the wrapper? AFAICS, having yet-to-be-annotated cases stick out... BTW, the goal this series is aiming at probably ought to be spelled out more clearly: there's a bunch of stacking-related stuff (overlayfs and ecryptfs in the tree, at least unionmount and aufs outside) that could benefit from having the notion "this dentry covers that stack of dentries from underlying fs layers" supported sanely by VFS, rather than having it open-coded in one way or another. And every place like that ends up in incestous relationship with VFS; it was annoying while it had been just ecryptfs, but it's getting worse now. Moreover, the details of behaviour overlayfs ends up having to rely upon are both potentially brittle *and* leaving quite a few things not working properly (starting with /proc/*/fd/* readlink, etc.) The goal behind all that massage is to have that notion (stacking) understood by VFS. And no, it's not related to the question of annotating ->d_inode accesses - just something that wasn't quite obvious from David's description. IMO it's worth spelling out somewhere in this thread...