From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH] AFS: Implement shared-writable mmap [try #2] Date: Thu, 17 May 2007 16:39:46 +1000 Message-ID: <464BF8B2.3080101@yahoo.com.au> References: <464B3F2D.9030603@yahoo.com.au> <464B3209.4010003@yahoo.com.au> <464B07EC.4050308@yahoo.com.au> <464AF3F3.30204@yahoo.com.au> <20070516100225.18685.51699.stgit@warthog.cambridge.redhat.com> <17173.1179321391@redhat.com> <19714.1179331928@redhat.com> <23262.1179334587@redhat.com> <31162.1179341123@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: David Howells Return-path: Received: from smtp105.mail.mud.yahoo.com ([209.191.85.215]:30922 "HELO smtp105.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757473AbXEQGj4 (ORCPT ); Thu, 17 May 2007 02:39:56 -0400 In-Reply-To: <31162.1179341123@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org David Howells wrote: > Nick Piggin wrote: > > >>You can drop the lock, do the invalidation, > > > Hmmm... There's a danger of incurring a race by doing that. Consider two > processes both trying to write to a dirty page for which writeback will be > rejected: > > (1) The first process gets EKEYREJECTED from the server, drops its lock and > is then preempted. > > (2) The second process gets EKEYREJECTED from the server, drops its lock, > truncates the page, reloads the page and modifies it. > > (3) The first process resumes and truncates the page, thereby splatting the > second process's write. > > Or: > > (1) The first process gets EKEYREJECTED from the server, clears the writeback > information from the page, drops its lock and is then preempted. > > (2) The second process attaches its own writeback information to the page and > modifies it. > > (3) The first process resumes and truncates the page, thereby splatting the > second process's write. If there are race issues involving concurrent invalidations, then you'd fix that up by taking a filesystem specific lock to prevent them. Generic write path should be holding i_mutex, but I don't think you can take that from page_mkwrite... Just add one of your own. > Really, what I want to do is pass the page lock to truncate to deal with. > Better still, I want truncate to be selective, based on whether or not a page > is still associated with the rejected writeback. I wonder if I should call > truncate_complete_page() or invalidate_complete_page() directly. No, you shouldn't. We could theoretically introduce a new API for this, but I think it would be preferable if you can fix the race in the fs. -- SUSE Labs, Novell Inc.