linux-kernel - Re: [PATCH 2/9] vfs: export do_splice

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: <CAJfpegssHT8s+hGf6mUV2fX0cxmU=R8gtjGLNxGz-WCyqXp=3Q@mail.gmail.com>
Date:	Wed, 20 Mar 2013 10:15:25 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Jan Kara <jack@...e.cz>, David Howells <dhowells@...hat.com>,
	torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, hch@...radead.org,
	akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
	neilb@...e.de, jordipujolp@...il.com, ezk@....cs.sunysb.edu,
	sedat.dilek@...glemail.com, hooanon05@...oo.co.jp, mszeredi@...e.cz
Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules

On Tue, Mar 19, 2013 at 10:24 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> it still might make sense to implement
> something as a layer, but some parts of that sucker may be better off as
> fs primitives.  Hell, we could, in theory, implement xattrs as a layer;
> just look at how reiserfs had done them.  We could do the same for hardlinks
> (look at qnx4, if you wish to see that hack).  Of for symlinks (sysvfs).
> Or for opened-and-unlinked files (sillyrename could be done as a generic
> layer).  Or for permissions/ownership/arbitrary names (umsdos, and that
> _was_ very similar to layering).  It's just that often an underlying fs
> has a better way of doing that.  IMO whiteouts are in that class.

My gut feeling is that whiteouts (and all that's related) are just too
specialized.  All the examples you listed are more general purpose.

I know one that could be useful for a variety of things, an "exchange"
operation.   While similar to rename, the semantics are much cleaner
and so the implementation becomes easier as well.

But that one doesn't quite solve the rename-with-whiteout thing.   For
that a three way permutation would be needed where one of the three is
an unlinked "floating" object.   That one is a really generic op but
we'd need to introduce linking unlinked objects into the tree which
comes with its own problems.

But I think it may be worth trying to come up with something more
generally useful before adding whiteouts and various overlay-specific
flags to filesystem code.

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/