To: torvalds@linux-foundation.org
CC: miklos@szeredi.hu, jens.axboe@oracle.com, akpm@linux-foundation.org,
       nickpiggin@yahoo.com.au, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, linux-mm@kvack.org
In-reply-to: <alpine.LFD.1.10.0807300958390.3334@nehalem.linux-foundation.org>
	(message from Linus Torvalds on Wed, 30 Jul 2008 10:00:28 -0700 (PDT))
Subject: Re: [patch v3] splice: fix race with page invalidation
References: <E1KO8DV-0004E4-6H@pomaz-ex.szeredi.hu> <alpine.LFD.1.10.0807300958390.3334@nehalem.linux-foundation.org>
Message-Id: <E1KOFUi-0000EU-0p@pomaz-ex.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 30 Jul 2008 19:29:48 +0200
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1195
Lines: 30

On Wed, 30 Jul 2008, Linus Torvalds wrote:
> On Wed, 30 Jul 2008, Miklos Szeredi wrote:
> > 
> > There are no real disadvantages: splice() from a file was
> > originally meant to be asynchronous, but in reality it only did
> > that for non-readahead pages, which happen rarely.
> 
> I still don't like this. I still don't see the point, and I still
> think there is something fundamentally wrong elsewhere.

We discussed the possible solutions with Nick, and came to the
conclusion, that short term (i.e. 2.6.27) this is probably the best
solution.

Long term sure, I have no problem with implementing async splice.

In fact, I may even have personal interest in looking at splice,
because people are asking for a zero-copy interface for fuse.

But that is definitely not 2.6.27, so I think you should reconsider
taking this patch, which is obviously correct due to its simplicity,
and won't cause any performance regressions either.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/