linux-kernel - Re: [patch 01/10] vfs: add path_create() and path

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: <20080403014622.GW9785@ZenIV.linux.org.uk>
Date:	Thu, 3 Apr 2008 02:46:22 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	dave@...ux.vnet.ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()

On Wed, Apr 02, 2008 at 09:37:01PM -0400, Erez Zadok wrote:
> Since you've hinted of major vfs changes post-25, here's my take.
> 
> Right now I (and to a similar extent ecryptfs too) needs to keep track of
> vfsmounts for various reasons:
> 
> - to grab a reference so the lower filesystems/mounts won't disappear on me

Umm...  Strictly speaking that's not true; you can grab an active reference
to superblock and then superblock will stay.  vfsmount is usually more
convenient, but that's it.

> - to pass it to dentry_open (opening the lower file)
> - some fs ops pass a vfsmount (umount_begin, show_options)

Thank Trond for the former, BTW ;-)  Both methods will be back to sanity;
for umount_begin() the only obstacle is cifs mess, where we do unconditional
(and bogus) work at each umount(2).  With that fixed, we'll be back to
calling it only for forced umount and passing it only superblock.
->show_options() can and should revert immediately after 2.6.25; thanks
for pointing that one out.

> - some fs ops or vfs helpers require a nameidata or struct path which embed
>   a vfsmount inside

*ONLY* ->follow_link().  Which has to, by definition...  The rest will be
gone by .26.

> - sometimes it's ok to pass NULL for those things, sometimes it's not ok

See above.  This crap will be gone.  For ->follow_link() nobody is allowed
to pass NULL as nameidata, period.

> In the longer run, is there a way that a stackable f/s could traverse the
> namespace below it w/o knowing or caring how they are composed (assorted r-w
> and r-o bind mounts and such)?

Eh?  Explain, please...
--
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/