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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
