From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [patch][rfc] mm: hold page lock over page_mkwrite Date: Wed, 25 Feb 2009 18:02:40 +0100 Message-ID: <20090225170240.GL22785@wotan.suse.de> References: <20090225093629.GD22785@wotan.suse.de> <49A5750A.1080006@oracle.com> <20090225165501.GK22785@wotan.suse.de> <49A5789E.4040600@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Linux Memory Management List , Mark Fasheh , Sage Weil To: Zach Brown Return-path: Received: from ns.suse.de ([195.135.220.2]:56205 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751163AbZBYRCn (ORCPT ); Wed, 25 Feb 2009 12:02:43 -0500 Content-Disposition: inline In-Reply-To: <49A5789E.4040600@oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: (Chris, your point about lock ordering is good. Zach raised the same one. Thanks for the good catch there guys). On Wed, Feb 25, 2009 at 08:58:06AM -0800, Zach Brown wrote: > > > Is ocfs2 immune to the races that get covered by this patch? > > I haven't the slightest idea. Well, they would be covered with the new scheme anyway: > > Hmm, actually possibly we can enter page_mkwrite with the page unlocked, > > but exit with the page locked? Slightly more complex, but should save > > complexity elsewhere. Yes I think this might be the best way to go. > > That sounds like it would work on first glance, yeah. Mark will yell at > us if we've gotten it wrong ;). OK, thanks. I'll go with that approach and see what happens.