linux-kernel - Re: Unexpected splice "always copy" behavior observed

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100519151726.GB2516@laptop>
Date:	Thu, 20 May 2010 01:17:26 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Pierre Tardy <tardyp@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	linux-kernel@...r.kernel.org, arjan@...radead.org,
	ziga.mahkovec@...il.com, davem <davem@...emloft.net>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Jens Axboe <jens.axboe@...cle.com>
Subject: Re: Unexpected splice "always copy" behavior observed

On Wed, May 19, 2010 at 07:39:11AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 19 May 2010, Nick Piggin wrote:
> > 
> > We can possibly do an attempt to invalidate existing pagecache and
> > then try to install the new page.
> 
> Yes, but that's going to be rather hairier. We need to make sure that the 
> filesystem doesn't have some kind of dirty pointers to the old page etc. 
> Although I guess that should always show up in the page counters, so I 
> guess we can always handle the case of page_count() being 1 (only page 
> cache) and the page being unlocked.

Well I mean a full invalidate -- invalidate_mapping_pages -- so there is
literally no pagecache there at all.

Then we just need to ensure that the filesystem doesn't do anything
funny with the page in write_begin (I don't know, such as zero out holes
or something strange). I don't think any do except maybe for something
obscure like jffs2, but obviously it needs to be looked at.

Error handling may need to be looked at too, but shouldn't be much
issue I'd think.
 
Even so, it's all going to add branches and complexity to an important
fast path, so we'd want to see numbers.


> So I'd much rather just handle the "append to the end".
> 
> The real limitation is likely always going to be the fact that it has to 
> be page-aligned and a full page. For a lot of splice inputs, that simply 
> won't be the case, and you'll end up copying for alignment reasons anyway.

That's true.

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