On Sat, Nov 14, 2009 at 1:06 AM, Josef Bacik <josef@xxxxxxxxxx> wrote: > We can race with the unmount of an fs and the stopping of a kthread where we > will free the block group before we're done using it. The reason for this is > because we do not hold a reference on the block group while its caching, since > the allocator drops its reference once it exits or moves on to the next block > group. This patch fixes the problem by taking a reference to the block group > before we start caching and dropping it when we're done to make sure all > accesses to the block group are safe. Thanks, > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxx> > --- > fs/btrfs/extent-tree.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index 2a4cdce..197bc1b 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -399,6 +399,8 @@ err: > > put_caching_control(caching_ctl); > atomic_dec(&block_group->space_info->caching_threads); > + btrfs_put_block_group(block_group); > + > return 0; > } > > @@ -439,6 +441,7 @@ static int cache_block_group(struct btrfs_block_group_cache *cache) > up_write(&fs_info->extent_commit_sem); > > atomic_inc(&cache->space_info->caching_threads); > + atomic_inc(&cache->count); > > tsk = kthread_run(caching_kthread, cache, "btrfs-cache-%llu\n", > cache->key.objectid); > -- This won't work since btrfs_free_block_groups call kfree without checking the reference count. I think the correct way to fix the race is waiting until caching threads exit Yan, Zheng -- 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
