From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
Subject: Re: [PATCH 7/9] fsfreeze: freeze_super and thaw_bdev don't play well
 together
Date: Wed, 03 Oct 2012 16:58:50 +0900
Message-ID: <506BF03A.3010803@lab.ntt.co.jp>
References: <1347605006.6868.2.camel@nexus.lab.ntt.co.jp> <1347605614.6868.9.camel@nexus.lab.ntt.co.jp> <20120925094828.GD8049@quack.suse.cz> <50618CB5.2010602@lab.ntt.co.jp> <20120925163942.GF8049@quack.suse.cz> <5062BB5D.1020508@lab.ntt.co.jp> <20120926090955.GA7678@quack.suse.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Josef Bacik <jbacik@fusionio.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Dave Chinner <dchinner@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org
To: Jan Kara <jack@suse.cz>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:58930 "EHLO
	tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755641Ab2JCICn (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 3 Oct 2012 04:02:43 -0400
In-Reply-To: <20120926090955.GA7678@quack.suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 2012/09/26 18:09, Jan Kara wrote:
>> I should have explained my fears better. If no one else
>> is holding an active reference we will end up executing:
>>
>> fs->kill_sb(s);
>> ...
>> put_filesystem(fs);
>> put_super(s);
>>
>> in deactivate_locked_super(). If s_count is greater than 0
>> the superblock will not be freed, as you say, however we
>> still do "fs->kill_sb(s)" and "put_filesystem(fs)" and I am not
>> sure whether this is safe when MS_BORN flag is not set in
>> the superblock. I will check how MS_BORN is being used
>> once more and try to figure it out (if you are familiar with
>> MS_BORN I would appreciate it your advise).
>    I see. Well, from a brief check I don't think we should ever get to a
> superblock without MS_BORN set. All functions iterating over superblocks
> return only superblocks with MS_BORN set. In particular freeze_bdev() even
> has an active reference itself and ioctl_fsfreeze() has a file open on the
> sb which guarantees an active reference as well...

As you say when we get there via the superblock level API
it is guaranteed that we have at least one active reference
and that MS_BORN is set. However, freeze_bdev() iterates
over superblocks using get_active_super() which can return
a superblock without the MS_BORN flag set; during sys_mount
mount_fs() sets the MS_BORN flag *after* sget() inserts the
superblock in all the lists.

If the analysis above is correct we do need the MS_BORN
check.

By the way, tomorrow I will be sending v5 of this patch set.

Thanks,
Fernando