]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
btrfs: call btrfs_orig_bbio_end_io in btrfs_end_bio_work
authorSasha Levin <sashal@kernel.org>
Tue, 6 Jun 2023 14:37:40 +0000 (10:37 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 9 Jun 2023 08:48:19 +0000 (10:48 +0200)
commit1d454bcf877ea17be5ad695967a9e722a6112eb8
treea953ee73d20e5d7dcd64ba070aacf92083f8200c
parent772235bb9c5996eacd5fedc26d0ad5c09017c834
btrfs: call btrfs_orig_bbio_end_io in btrfs_end_bio_work

[ Upstream commit 45c2f36871955b51b4ce083c447388d8c72d6b91 ]

When I implemented the storage layer bio splitting, I was under the
assumption that we'll never split metadata bios.  But Qu reminded me that
this can actually happen with very old file systems with unaligned
metadata chunks and RAID0.

I still haven't seen such a case in practice, but we better handled this
case, especially as it is fairly easily to do not calling the ->end_іo
method directly in btrfs_end_io_work, and using the proper
btrfs_orig_bbio_end_io helper instead.

In addition to the old file system with unaligned metadata chunks case
documented in the commit log, the combination of the new scrub code
with Johannes pending raid-stripe-tree also triggers this case.  We
spent some time debugging it and found that this patch solves
the problem.

Fixes: 103c19723c80 ("btrfs: split the bio submission path into a separate file")
CC: stable@vger.kernel.org # 6.3+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Tested-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/btrfs/bio.c