From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [patch v3] splice: fix race with page invalidation Date: Wed, 30 Jul 2008 17:54:20 -0700 (PDT) Message-ID: References: <20080731001131.GA30900@shareable.org> <20080731004214.GA32207@shareable.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Miklos Szeredi , 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 To: Jamie Lokier Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:59802 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752759AbYGaA6P (ORCPT ); Wed, 30 Jul 2008 20:58:15 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 30 Jul 2008, Linus Torvalds wrote: > > 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(). Side note: in-kernel users could probably do somethign about this. IOW, if there's some in-kernel usage (and yes, knfsd would be a prime example), that one may actually be able to do things that a _user_level user of splice() could never do. That includes things like getting the inode semaphore over a write (so that you can guarantee that pages that are in flight are not modified, except again possibly by other mmap users), and/or a per-page callback for when splice() is done with a page (so that you could keep the page locked while it's getting spliced, for example). And no, we don't actually have that either, of course. Linus