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: <200804030137.m331b1O8004886@agora.fsl.cs.sunysb.edu>
Date:	Wed, 2 Apr 2008 21:37:01 -0400
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Erez Zadok <ezk@...sunysb.edu>,
	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() 

In message <20080403010016.GU9785@...IV.linux.org.uk>, Al Viro writes:
> On Wed, Apr 02, 2008 at 08:47:06PM -0400, Erez Zadok wrote:
> > In message <1207183329.20254.49.camel@...mdal.trondhjem.org>, Trond Myklebust writes:
> > > 
> > > On Thu, 2008-04-03 at 00:47 +0100, Al Viro wrote:
> > [...]
> > > >  Again, what for?
> > > 
> > > It allows you to get rid of the vfsmount 'argument' when opening a file,
> > > which again lowers the barrier for stacking filesystems.
> > > 
> > > As far as the filesystems themselves are concerned, the effect is to
> > > enforce your assertion that file operations should not depend on the
> > > namespace.
> > 
> > I'd be delighted the day I won't have to deal with vfsmounts AT ALL in
> > any stacked f/s.
> 
> vfsmounts or the fact that any fs may be mounted in many places?

I think the former.  The fact that any f/s can be mounted in many places,
should be fine for a stacked f/s (topology changes as we discussed before
are a different problem).

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
- to pass it to dentry_open (opening the lower file)
- some fs ops pass a vfsmount (umount_begin, show_options)
- some fs ops or vfs helpers require a nameidata or struct path which embed
  a vfsmount inside
- sometimes it's ok to pass NULL for those things, sometimes it's not ok

Often it also appears that a vfsmount and a dentry tuple are needed
together, hence struct path.  So we recently started using struct path in a
few places, and using path_get/put.  The need to deal with <dentry,vfsmount>
pairs by hand can lead to interesting bugs, such as the recent ecryptfs
bugfix which had to swap the order of a dput() and mntput() sequence.

The fact that several vfs ops and helpers take different namespace-related
structures (dentry, nameidata, vfsmount, path), is confusing and hard to
track.  Is there a way to reduce the number of those structures to 1-2 at
most?

For a stackable f/s, it's important the the VFS ops *and* the VFS helpers
(vfs_*, path_*, dentry_open, etc.) use the same namespace structures: then
there's more symmetry b/t the objects passed to a stacked f/s, and the
objects it has to pass to VFS helpers (and FWIW, every such object should
ideally leave a "void *private" field for f/s specific extensibility).

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)?

Cheers,
Erez.
--
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/