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]

Date:	Wed, 02 Apr 2008 20:42:09 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	dave@...ux.vnet.ibm.com, ezk@...sunysb.edu,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()

On Thu, 2008-04-03 at 00:47 +0100, Al Viro wrote:
> On Thu, Apr 03, 2008 at 12:40:43AM +0100, Al Viro wrote:
> > Anyway, what the hell for?  It's more complex and buys you nothing
> > useful.
> 
> BTW, what it gives you is an extra headache for scenarios like
> 
> task A:
> 	write(fd, ...)
> task B:	/* shares descriptor table with A */
> 	close(fd)
> task C: umount(<mountpoint of tree where fd is>)
> ...
> task A: still writing
> 
> At the very least, you want "that thing is still busy" on normal umount -
> we are still in the middle of write(2) and hell knows how long it's going
> to last.  So you need to play with refcount of vfsmount in a very nasty
> way, for all your pains. 

We already call fget_light()/fput_light() around the whole call to
vfs_write(). Substituting a call to something which takes a reference to
the new structure is trivial.

Once the write() syscall is done, and the file is closed, why should we
refuse the umount request? There should be nothing more going on that
depends on the namespace.

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

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