starfive-tech/u-boot.git - StarFive Tech U-Boot for VisionFive (JH7110) boards (mirror)

Age	Commit message (Collapse)	Author	Files	Lines
2023-02-23	fs: btrfs: limit the mapped length to the original length	Qu Wenruo	1	-0/+2
	[BUG] There is a bug report that btrfs driver caused hang during file read: This breaks btrfs on the HiFive Unmatched. => pci enum PCIE-0: Link up (Gen1-x8, Bus0) => nvme scan => load nvme 0:2 0x8c000000 /boot/dtb/sifive/hifive-unmatched-a00.dtb [hangs] [CAUSE] The reporter provided some debug output: read_extent_data: cur=615817216, orig_len=16384, cur_len=16384 read_extent_data: btrfs_map_block: cur_len=479944704; ret=0 read_extent_data: ret=0 read_extent_data: cur=615833600, orig_len=4096, cur_len=4096 read_extent_data: btrfs_map_block: cur_len=479928320; ret=0 Note the second and the last line, the @cur_len is 450+MiB, which is almost a chunk size. And inside __btrfs_map_block(), we limits the returned value to stripe length, but that's depending on the chunk type: if (map->type & (BTRFS_BLOCK_GROUP_RAID0 \| BTRFS_BLOCK_GROUP_RAID1 \| BTRFS_BLOCK_GROUP_RAID1C3 \| BTRFS_BLOCK_GROUP_RAID1C4 \| BTRFS_BLOCK_GROUP_RAID5 \| BTRFS_BLOCK_GROUP_RAID6 \| BTRFS_BLOCK_GROUP_RAID10 \| BTRFS_BLOCK_GROUP_DUP)) { /* we limit the length of each bio to what fits in a stripe / length = min_t(u64, ce->size - offset, map->stripe_len - stripe_offset); } else { *length = ce->size - offset; } This means, if the chunk is SINGLE profile, then we don't limit the returned length at all, and even for other profiles, we can still return a length much larger than the requested one. [FIX] Properly clamp the returned length, preventing it from returning a much larger range than expected. Reported-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Qu Wenruo <wqu@suse.com>
2021-01-20	fs: btrfs: volumes: prevent overflow for multiplying	Qu Wenruo	1	-2/+2
	In __btrfs_map_block() we do a int * int and assign it to u64. This is not safe as the result (int * int) is still evaluated as (int) thus it can overflow. Convert one of the multiplier to u64 to prevent such problem. In real world, this should not cause problem as we have device number limit thus it won't go beyond 4G for a single stripe. But it's harder to teach coverity about all these hidden limits, so just fix the possible overflow. Reported-by: Coverity CID 312957 Reported-by: Coverity CID 312948 Signed-off-by: Qu Wenruo <wqu@suse.com>
2020-09-08	fs: btrfs: Crossport btrfs_read_sys_array() and btrfs_read_chunk_tree()	Qu Wenruo	1	-0/+301
	These two functions play a big role in btrfs bootstrap. The following function is removed: - Seed device support Although in theory we can still support multiple devices, we don't have a facility in U-Boot to do device scan without opening them. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2020-09-08	fs: btrfs: Crossport volumes.[ch] from btrfs-progs	Qu Wenruo	1	-0/+872
	This patch crossports volumes.[ch] from btrfs-progs, including: - btrfs_map_block() The core mechanism to map btrfs logical address to physical address. This version includes multi-device support, along with RAID56 support. - btrfs_scan_one_device() This is the function to register one btrfs device to the list. This is the main part of the multi-device btrfs assembling process. Although we're not going to support multiple devices until U-Boot allows us to scan one device without actually opening it. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz> [trini: Use %zu in a debug print to avoid warning] Signed-off-by: Tom Rini <trini@konsulko.com>