Skip to content

Commit 1e61b8c

Browse files
josefbacikkdave
authored andcommitted
btrfs: don't unconditionally call folio_start_writeback in subpage
In the normal case we check if a page is under writeback and skip it before we attempt to begin writeback. The exception is subpage metadata writes, where we know we don't have an eb under writeback and we're doing it one eb at a time. Since b5612c3 ("mm: return void from folio_start_writeback() and related functions") we now will BUG_ON() if we call folio_start_writeback() on a folio that's already under writeback. Previously folio_start_writeback() would bail if writeback was already started. Fix this in the subpage code by checking if we have writeback set and skipping it if we do. This fixes the panic we were seeing on subpage. Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
1 parent 2018ef1 commit 1e61b8c

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

fs/btrfs/subpage.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -475,7 +475,8 @@ void btrfs_subpage_set_writeback(const struct btrfs_fs_info *fs_info,
475475

476476
spin_lock_irqsave(&subpage->lock, flags);
477477
bitmap_set(subpage->bitmaps, start_bit, len >> fs_info->sectorsize_bits);
478-
folio_start_writeback(folio);
478+
if (!folio_test_writeback(folio))
479+
folio_start_writeback(folio);
479480
spin_unlock_irqrestore(&subpage->lock, flags);
480481
}
481482

0 commit comments

Comments
 (0)