Re: [PATCH] btrfs: add a test case to verify the write behavior of large RAID5 data chunks

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]





On 2023/6/23 01:23, David Sterba wrote:
On Thu, Jun 22, 2023 at 02:54:38PM +0800, Qu Wenruo wrote:
There is a recent regression during v6.4 merge window, that a u32 left
shift overflow can cause problems with large data chunks (over 4G)
sized.

This is especially nasty for RAID56, which can lead to ASSERT() during
regular writes, or corrupt memory if CONFIG_BTRFS_ASSERT is not enabled.

This is the regression test case for it.

I am not able to reproduce the problem with the previous fix
a7299a18a179a971 applied

Well, it's 100% reproducible here.

And the missing type cast is indeed the cause inside btrfs_map_block():

        if (map->type & BTRFS_BLOCK_GROUP_RAID56_MASK && need_raid_map &&
            (op != BTRFS_MAP_READ || mirror_num > 1)) {
                bioc->full_stripe_logical = em->start +
                        ((stripe_nr * data_stripes) <<
BTRFS_STRIPE_LEN_SHIFT);

Obviously @stripe_nr (now the full stripe number) * @data_stripes can
reach stripe number beyond 4G range.

And a left shift would lead to overflow, causing a too small value.

This would trigger the ASSERT() in the raid56 code of rbio_add_bio().


I'm not sure why it didn't trigger in your case, mind to share the
seqres.full?

Thanks,
Qu

but not the additional one so I can't validate
the fix and will have to postpone sending the pull request.




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux