From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH vfs-2.6:for-next] vfs: remount_fs BKL pushdown
Date: Wed, 6 May 2009 04:51:38 +0100
Message-ID: <20090506035138.GP8633@ZenIV.linux.org.uk>
References: <1240646945-7970-1-git-send-email-abogani@texware.it> <20090425082349.GA2475@infradead.org> <20090505133743.GA663@infradead.org> <63a49ef40905051239r61fe7f4cg6f24e13df30dc940@mail.gmail.com> <20090505204352.GA23343@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Alessio Igor Bogani <abogani@texware.it>,
	Jonathan Corbet <corbet@lwn.net>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	LKML <linux-kernel@vger.kernel.org>,
	LFSDEV <linux-fsdevel@vger.kernel.org>,
	Matthew Wilcox <matthew@wil.cx>, Ingo Molnar <mingo@elte.hu>
To: Christoph Hellwig <hch@infradead.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:39760 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758873AbZEFDvp (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 5 May 2009 23:51:45 -0400
Content-Disposition: inline
In-Reply-To: <20090505204352.GA23343@infradead.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, May 05, 2009 at 04:43:52PM -0400, Christoph Hellwig wrote:
> On Tue, May 05, 2009 at 09:39:38PM +0200, Alessio Igor Bogani wrote:
> > >> Please also push down lock_super, no need to have two locking changes in
> > >> this area just after another.
> > >
> > > Do you plan to do that respin? ?I will need the lock_super pushdown for
> > > some sync work. ?I can wait for you if you plan to submit it, otherwise
> > > I'll out it on my TODO list.
> > 
> > Apologize I have completely missed your first replay.
> > 
> > Let me two days for finish that task and for do build and boot tests.
> 
> Great!  Thanks a lot for the effort.

Actually, I'm not sure that you are right.  Especially if we go for your
"always hold s_umount for sync_filesystem()"; in that case we are guaranteed
that we'll have an exclusion between ->write_super() and that sucker, so
there's no reason to push it down into filesystems that do not use lock_super()
at all.  And that'd be most of them...

Note that I've taken all callers of remount under exclusive s_umount (see
#untested in the vfs tree).