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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20100518161308.GL2516@laptop>
Date:	Wed, 19 May 2010 02:13:08 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.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>,
	Tejun Heo <tj@...nel.org>, Jens Axboe <jens.axboe@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Unexpected splice "always copy" behavior observed

On Wed, May 19, 2010 at 02:00:51AM +1000, Nick Piggin wrote:
> On Tue, May 18, 2010 at 10:56:24AM -0500, Christoph Lameter wrote:
> > On Wed, 19 May 2010, Nick Piggin wrote:
> > 
> > > What would be needed is to have filesystem maintainers go through and
> > > enable it on a case by case basis. It's trivial for tmpfs/ramfs type
> > > filesystems and I have a patch for those, but I never posted it on.yet.
> > > Even basic buffer head filesystems IIRC get a little more complex --
> > > but we may get some milage just out of invalidating the existing
> > > pagecache rather than getting fancy and trying to move buffers over
> > > to the new page.
> > 
> > There is a "migration" address space operation for moving pages. Page
> > migration requires that in order to be able to move dirty pages. Can
> > splice use that?
> 
> Hmm yes I didn't think of that, it probably could.

It's not the only requirement, of course, just that it could
potentially reuse some of the code.

The big difference is that the source page is already dirty, and
the destination page might not exist, might exist and be partially
uptodate, not have blocks allocated, might be past i_size, fully
uptodate, etc.

So it's more than a matter of just a simple copy to another page
and taking over exactly the same filesystem state as the old page.

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