Skip to content

Commit fc1f91b

Browse files
josefbacikkdave
authored andcommitted
btrfs: wait for actual caching progress during allocation
Recently we've been having mysterious hangs while running generic/475 on the CI system. This turned out to be something like this: Task 1 dmsetup suspend --nolockfs -> __dm_suspend -> dm_wait_for_completion -> dm_wait_for_bios_completion -> Unable to complete because of IO's on a plug in Task 2 Task 2 wb_workfn -> wb_writeback -> blk_start_plug -> writeback_sb_inodes -> Infinite loop unable to make an allocation Task 3 cache_block_group ->read_extent_buffer_pages ->Waiting for IO to complete that can't be submitted because Task 1 suspended the DM device The problem here is that we need Task 2 to be scheduled completely for the blk plug to flush. Normally this would happen, we normally wait for the block group caching to finish (Task 3), and this schedule would result in the block plug flushing. However if there's enough free space available from the current caching to satisfy the allocation we won't actually wait for the caching to complete. This check however just checks that we have enough space, not that we can make the allocation. In this particular case we were trying to allocate 9MiB, and we had 10MiB of free space, but we didn't have 9MiB of contiguous space to allocate, and thus the allocation failed and we looped. We specifically don't cycle through the FFE loop until we stop finding cached block groups because we don't want to allocate new block groups just because we're caching, so we short circuit the normal loop once we hit LOOP_CACHING_WAIT and we found a caching block group. This is normally fine, except in this particular case where the caching thread can't make progress because the DM device has been suspended. Fix this by not only waiting for free space to >= the amount of space we want to allocate, but also that we make some progress in caching from the time we start waiting. This will keep us from busy looping when the caching is taking a while but still theoretically has enough space for us to allocate from, and fixes this particular case by forcing us to actually sleep and wait for forward progress, which will flush the plug. With this fix we're no longer hanging with generic/475. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
1 parent b28ff3a commit fc1f91b

File tree

2 files changed

+17
-2
lines changed

2 files changed

+17
-2
lines changed

fs/btrfs/block-group.c

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -441,13 +441,23 @@ void btrfs_wait_block_group_cache_progress(struct btrfs_block_group *cache,
441441
u64 num_bytes)
442442
{
443443
struct btrfs_caching_control *caching_ctl;
444+
int progress;
444445

445446
caching_ctl = btrfs_get_caching_control(cache);
446447
if (!caching_ctl)
447448
return;
448449

450+
/*
451+
* We've already failed to allocate from this block group, so even if
452+
* there's enough space in the block group it isn't contiguous enough to
453+
* allow for an allocation, so wait for at least the next wakeup tick,
454+
* or for the thing to be done.
455+
*/
456+
progress = atomic_read(&caching_ctl->progress);
457+
449458
wait_event(caching_ctl->wait, btrfs_block_group_done(cache) ||
450-
(cache->free_space_ctl->free_space >= num_bytes));
459+
(progress != atomic_read(&caching_ctl->progress) &&
460+
(cache->free_space_ctl->free_space >= num_bytes)));
451461

452462
btrfs_put_caching_control(caching_ctl);
453463
}
@@ -802,8 +812,10 @@ static int load_extent_tree_free(struct btrfs_caching_control *caching_ctl)
802812

803813
if (total_found > CACHING_CTL_WAKE_UP) {
804814
total_found = 0;
805-
if (wakeup)
815+
if (wakeup) {
816+
atomic_inc(&caching_ctl->progress);
806817
wake_up(&caching_ctl->wait);
818+
}
807819
}
808820
}
809821
path->slots[0]++;
@@ -910,6 +922,7 @@ int btrfs_cache_block_group(struct btrfs_block_group *cache, bool wait)
910922
init_waitqueue_head(&caching_ctl->wait);
911923
caching_ctl->block_group = cache;
912924
refcount_set(&caching_ctl->count, 2);
925+
atomic_set(&caching_ctl->progress, 0);
913926
btrfs_init_work(&caching_ctl->work, caching_thread, NULL, NULL);
914927

915928
spin_lock(&cache->lock);

fs/btrfs/block-group.h

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -90,6 +90,8 @@ struct btrfs_caching_control {
9090
wait_queue_head_t wait;
9191
struct btrfs_work work;
9292
struct btrfs_block_group *block_group;
93+
/* Track progress of caching during allocation. */
94+
atomic_t progress;
9395
refcount_t count;
9496
};
9597

0 commit comments

Comments
 (0)