linux-kernel - Re: [PATCH 12/15] VFS: Add owner-filesystem positive/negative dentry checks

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]

Message-ID: <CAJfpegue3OvFwxCUiRuGJxCMQV_jrtYoGoZywRz_kLykKbQU4w@mail.gmail.com>
Date:	Thu, 26 Mar 2015 14:05:07 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@....linux.org.uk,
	"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/15] VFS: Add owner-filesystem positive/negative dentry checks

On Wed, Mar 25, 2015 at 3:45 PM, David Howells <dhowells@...hat.com> wrote:
> Supply two functions to test whether a filesystem's own dentries are positive
> or negative (d_really_is_positive() and d_really_is_negative()).
>
> The problem is that the DCACHE_ENTRY_TYPE field of dentry->d_flags may be
> overridden by the union part of a layered filesystem and isn't thus
> necessarily indicative of the type of dentry.
>
> Normally, this would involve a negative dentry (ie. ->d_inode == NULL) having
> ->d_layer.lower pointed to a lower layer dentry, DCACHE_PINNING_LOWER set and
> the DCACHE_ENTRY_TYPE field set to something other than DCACHE_MISS_TYPE - but
> it could also involve, say, a DCACHE_SPECIAL_TYPE being overridden to
> DCACHE_WHITEOUT_TYPE if a 0,0 chardev is detected in the top layer.
>
> However, inside a filesystem, when that fs is looking at its own dentries, it
> probably wants to know if they are really negative or not - and doesn't care
> about the fallthrough bits used by the union.
>
> To this end, a filesystem should normally use d_really_is_positive/negative()
> when looking at its own dentries rather than d_is_positive/negative() and
> should use d_inode() to get at the inode.
>
> Anyone looking at someone else's dentries (this includes pathwalk) should use
> d_is_xxx() and d_backing_inode().

I think this is confusing as hell, there needs to be more consistency
in the naming.  E.g. d_backing_is_positive() vs. d_is_positive().   I
know it's the other way round now, but only with a few users.  Also a
separate include file might help, that needs explicit including to get
the "backing" variants and which would have big fat warnings all over.

Thanks,
Miklos
--
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/