linux-kernel - Re: [git pull] more vfs bits

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]

Date:	Sun, 22 Feb 2015 01:32:28 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Howells <dhowells@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] more vfs bits

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...
--
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/