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: <1274287002.26328.808.camel@gandalf.stny.rr.com>
Date:	Wed, 19 May 2010 12:36:42 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	mathieu.desnoyers@...icios.com, peterz@...radead.org,
	fweisbec@...il.com, tardyp@...il.com, mingo@...e.hu,
	acme@...hat.com, tzanussi@...il.com, paulus@...ba.org,
	linux-kernel@...r.kernel.org, arjan@...radead.org,
	ziga.mahkovec@...il.com, davem@...emloft.net, linux-mm@...ck.org,
	akpm@...ux-foundation.org, kosaki.motohiro@...fujitsu.com,
	cl@...ux-foundation.org, tj@...nel.org, jens.axboe@...cle.com
Subject: Re: Unexpected splice "always copy" behavior observed

On Thu, 2010-05-20 at 01:55 +1000, Nick Piggin wrote:
> On Wed, May 19, 2010 at 11:45:42AM -0400, Steven Rostedt wrote:

> > If the "move only on append to file" is easy to implement, I would
> > really like to see that happen. The speed of splicing a disk image for a
> > virtual machine only impacts the patience of the user. The speed of
> > splicing tracing output, impacts how much you can trace without losing
> > events.
> 
> It's not "easy" to implement :) What's your ring buffer look like?
> Is it a normal user address which the kernel does copy_to_user()ish
> things into? Or a mmapped special driver?

Neither ;-)

> 
> If the latter, it get's even harder again. But either way if the
> source pages just have to be regenerated anyway (eg. via page fault
> on next access), then it might not even be worthwhile to do the
> splice move.

The ring buffer is written to by kernel events. To read it, the user can
either do a sys_read() and that is copied, or use splice. I do not
support mmap(), and if we were to do that, it would then not support
splice(). We have been talking about implementing both but with flags on
allocation of the ring buffer. You can either support mmap() or splice()
but not both with one instance of the ring buffer.

-- Steve





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