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: <20130320214813.GS21522@ZenIV.linux.org.uk>
Date:	Wed, 20 Mar 2013 21:48:13 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Jan Kara <jack@...e.cz>
Cc:	David Howells <dhowells@...hat.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	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 Wed, Mar 20, 2013 at 08:52:22PM +0100, Jan Kara wrote:
> > do_bio_filebacked(), with some ugliness between that and callsite.  Note,
> > BTW, that we have a pair of possible vfs_fsync() calls in there; how do those
> > interact with freeze?
>   Freezing code takes care that all dirty data is synced before fs is
> frozen and no new dirty data can be created before fs is thawed. So
> vfs_fsync() should just return without doing anything on frozen filesystem.

Um...  How does it interact with vfs_fsync() already in progress when you
ask to freeze it?

Anyway, I've pulled the fscker out of ->aio_write, ->write and ->splice_write;
on that pathway it's in the do_splice_from() (see vfs.git#experimental).

... and now, for something *really* nasty: where do mandatory file locks
belong in the locking hierarchy?  Relative to fsfreeze one, for starters,
but both for unionmount and overlayfs we need to decide where they live
relative to ->i_mutex on directories.

And that, BTW, may be the strongest argument so far in favour of the scheme
I'd suggested for copyup-via-opened-but-unlinked...
--
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/