Re: [PATCH 2/2] Btrfs: fix deadlock on sb->s_umount when doing umount

[Miao Xie <miaox@cn.fujitsu.com>]

On tue, 6 Dec 2011 05:49:06 +0000, Al Viro wrote:
> 
>> +void btrfs_writeback_inodes_sb_nr(struct btrfs_root *root,
>> +				  unsigned long nr_pages)
>> +{
>> +	struct super_block *sb = root->fs_info->sb;
>> +
>> +	if (writeback_in_progress(sb->s_bdi))
>> +		return;
>> +
>> +	/*
>> +	 * If we can not get s_umount, it means the fs is on remounting or
>> +	 * umounting. At this time, we just sync all the delalloc file.
>> +	 */
>> +	if (down_read_trylock(&sb->s_umount)) {
>> +		writeback_inodes_sb_nr(sb, nr_pages);
>> +		up_read(&sb->s_umount);
>> +	} else {
>> +		btrfs_start_delalloc_inodes(root, 0);
>> +		btrfs_wait_ordered_extents(root, 0, 0);
>> +	}
>> +}
> 
> If that can race with umount, what prevents sb, its ->s_bdi et.al. being freed
> under you?

In fact, it happened. See the following mail.

   http://marc.info/?l=linux-btrfs&m=131495252725296&w=2

The above function is called when some one want to modify the meta-data.
Btrfs will wait until all the meta-data operations end, and then free ->s_bdi
and the other objects. So we needn't worry about those objects.
(Maybe I misunderstood what you said. If yes, I'm sorry)

Thanks
Miao

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>