linux-kernel - Re: [patch v3] splice: fix race with page invalidation

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: <alpine.LFD.1.10.0807301746500.3277@nehalem.linux-foundation.org>
Date:	Wed, 30 Jul 2008 17:51:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jamie Lokier <jamie@...reable.org>
cc:	Miklos Szeredi <miklos@...redi.hu>, jens.axboe@...cle.com,
	akpm@...ux-foundation.org, nickpiggin@...oo.com.au,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch v3] splice: fix race with page invalidation

On Thu, 31 Jul 2008, Jamie Lokier wrote:
>
> Jamie Lokier wrote:
> > not being able to tell when a sendfile() has finished with the pages
> > its sending.
> 
> (Except by the socket fully closing or a handshake from the other end,
> obviously.)

Well, people should realize that this is pretty fundamental to zero-copy 
scemes. It's why zero-copy is often much less useful than doing a copy in 
the first place. How do you know how far in a splice buffer some random 
'struct page' has gotten? Especially with splicing to spicing to tee to 
splice...

You'd have to have some kind of barrier model (which would be really 
complex), or perhaps a "wait for this page to no longer be shared" (which 
has issues all its own).

IOW, splice() is very closely related to a magic kind of "mmap()+write()" 
in another thread. That's literally what it does internally (except the 
"mmap" is just a small magic kernel buffer rather than virtual address 
space), and exactly as with mmap, if you modify the file, the other thread 
will see if, even though it did it long ago.

Personally, I think the right approach is to just realize that splice() is 
_not_ a write() system call, and never will be. If you need synchronous 
writing, you simply shouldn't use splice().

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