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: <200807312249.02287.nickpiggin@yahoo.com.au>
Date:	Thu, 31 Jul 2008 22:49:01 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Miklos Szeredi <miklos@...redi.hu>, jens.axboe@...cle.com,
	akpm@...ux-foundation.org, 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 Thursday 31 July 2008 22:33, Jamie Lokier wrote:
> Evgeniy Polyakov wrote:
> > On Thu, Jul 31, 2008 at 07:12:01AM +0100, Jamie Lokier 
(jamie@...reable.org) wrote:
> > > The obvious mechanism for completion notifications is the AIO event
> > > interface.  I.e. aio_sendfile that reports completion when it's safe
> > > to modify data it was using.  aio_splice would be logical for similar
> > > reasons.  Note it doesn't mean when the data has reached a particular
> > > place, it means when the pages it's holding are released.  Pity AIO
> > > still sucks ;-)
> >
> > It is not that simple: page can be held in hardware or tcp queues for
> > a long time, and the only possible way to know, that system finished
> > with it, is receiving ack from the remote side. There is a project to
> > implement such a callback at skb destruction time (it is freed after ack
> > from the other peer), but do we really need it? System which does care
> > about transmit will implement own ack mechanism, so page can be unlocked
> > at higher layer. Actually page can be locked during transfer and
> > unlocked after rpc reply received, so underlying page invalidation will
> > be postponed and will not affect sendfile/splice.
>
> This is why marking the pages COW would be better.  Automatic!
> There's no need for a notification, merely letting go of the page
> references - yes, the hardware / TCP acks already do that, no locking
> or anything!  :-)  The last reference is nothing special, it just means
> the next file write/truncate sees the count is 1 and doesn't need to
> COW the page.

Better == more bloat and complexity and corner cases in the VM?

If the app wants to ensure some specific data is sent, then it has
to wait until the receiver receives it before changing it, simple.

And you still don't avoid the fundamental problem that the receiver
may not get exactly what the sender has put in flight if we do things
asynchronously.
--
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/