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:	Sat, 21 Feb 2015 17:34:23 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	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 4:51 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Looking at that queue, it might make sense to hold back everything in that
> series past "fanotify: Fix up scripted S_ISDIR/S_ISREG/S_ISLNK conversions"
> for now

Hmm. Even I'd pull just that, quite frankly, I just think it's
*confusing* to have those badly named "helpers", that were introduced
earlier in that series.

These guys are currently all teh same thing, but even if they weren't,
the naming is not helpful, and not sane:
 - fs_inode
 - fs_inode_once
 - dentry_inode
 - dentry_inode_once

Let's walk through them:

 - dentry_inode*() is supposed to be "the inode that would be used if
the dentry was opened"

   What part of "dentry_inode()" implies "if the dentry was opened" to
you? Nothing. The name is fundamentally bad.

  And what *possible* situation could make that "_once()" version ever
be valid? None. It's bogus. It's crap. It's insane. There is no way
that it is *ever* a valid question to even ask. If the dentry is so
unstable that you can't safely look at the inode, you had damn well
better never ask "ok, what would the inode be if I opened this random
pointer"?

   So one of them is badly named, and the other one is fundamentally
not a valid operation at all, as far as I can tell.

 - fs_inode*() is supposed to be "this is the inode that the native
filesystem uses".

   So again, I think the naming is horrible, since it doesn't really
follow the normal dentry helper routine names. But I'm sure we have
other cases where we screwed that up, so whatever..

   The "_once()" naming is doubly bad, as explained elsewhere. What
possible situation merits using that helper? If it's just
revalidate(), then make it about that.

   But more importantly, this is the one where I don't see how it
could ever possibly be anything but "dentry->d_inode". I'd much rather
just leave that.

So of the four new helpers, I really don't see any of them as "good".
I think "dentry_inode()" could remain, but even there I think the name
should specify *what* it is ("d_opened_inode()"? I don't like that
name either, but at least it would try to explain what the point is,
rather than having to look up a comment above the function definition
to figure out what the point is)

The strongest argument I've seen for them existing at all was that
"markers for what has been looked at". But that's something that
belongs in a development tree, not as a series to confuse others with.

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