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: <CAJfpegvqosGZZkbd=JbtYFWxHe_QugvFO8k+jpdYbKh92SUuDQ@mail.gmail.com>
Date:	Tue, 19 Mar 2013 12:40:18 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	David Howells <dhowells@...hat.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	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 12:04 PM, David Howells <dhowells@...hat.com> wrote:
> Miklos Szeredi <miklos@...redi.hu> wrote:
>
>> > BTW, I wonder what's the right locking for that sucker; overlayfs is
>> > probably too heavy - we are talking about copying a file from one fs to
>> > another, which can obviously take quite a while, so holding ->i_mutex on
>> > _parent_ all along is asking for very serious contention.
>>
>> Copy up is a once-in-a-lifetime event for an object.  Optimizing it is
>> way down in the list of things to do.  I'd drop splice in a jiffy if
>> it's in the way.
>
> Yes, but it could block the parent directory for a long time.  I suspect it's
> fine if you can RCU walk through the parent, but if you have to grab a lock on
> it...

Right.

Lets look at it this way:  users of an overlay accept that an
operation X can take T time, where T is much longer than would be on a
normal filesystem.  Then why would they complain that operation Y
(which happens to bump into the parent lock of X) also takes T?

If copy up of huge files happens more then very very occasionally,
then the overlay will be basically unusable anyway.  It's just not
what it is designed for, so why try to optimize this case?

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/