btrfs: update flush method assertion when reserving space
authorFilipe Manana <fdmanana@suse.com>
Tue, 21 Mar 2023 11:13:41 +0000 (11:13 +0000)
committerDavid Sterba <dsterba@suse.com>
Mon, 17 Apr 2023 16:01:18 +0000 (18:01 +0200)
When reserving space, at space-info.c:__reserve_bytes(), we assert that
either the current task is not holding a transacion handle, or, if it is,
that the flush method is not BTRFS_RESERVE_FLUSH_ALL. This is because that
flush method can trigger transaction commits, and therefore could lead to
a deadlock.

However there are other 2 flush methods that can trigger transaction
commits:

1) BTRFS_RESERVE_FLUSH_ALL_STEAL
2) BTRFS_RESERVE_FLUSH_EVICT

So update the assertion to check the flush method is also not one those
two methods if the current task is holding a transaction handle.

Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/space-info.c

index 3eecce8..379a0e7 100644 (file)
@@ -1603,7 +1603,18 @@ static int __reserve_bytes(struct btrfs_fs_info *fs_info,
        bool pending_tickets;
 
        ASSERT(orig_bytes);
-       ASSERT(!current->journal_info || flush != BTRFS_RESERVE_FLUSH_ALL);
+       /*
+        * If have a transaction handle (current->journal_info != NULL), then
+        * the flush method can not be neither BTRFS_RESERVE_FLUSH_ALL* nor
+        * BTRFS_RESERVE_FLUSH_EVICT, as we could deadlock because those
+        * flushing methods can trigger transaction commits.
+        */
+       if (current->journal_info) {
+               /* One assert per line for easier debugging. */
+               ASSERT(flush != BTRFS_RESERVE_FLUSH_ALL);
+               ASSERT(flush != BTRFS_RESERVE_FLUSH_ALL_STEAL);
+               ASSERT(flush != BTRFS_RESERVE_FLUSH_EVICT);
+       }
 
        if (flush == BTRFS_RESERVE_FLUSH_DATA)
                async_work = &fs_info->async_data_reclaim_work;