Re: [Patch v2 41/42] btrfs: fix the use-after-free bug in writeback subpage helper
From: Ritesh Harjani <hidden>
Date: 2021-05-25 09:23:16
On 21/05/25 02:14PM, Qu Wenruo wrote:
On 2021/5/25 下午1:52, Qu Wenruo wrote:quoted
On 2021/5/25 下午12:43, Ritesh Harjani wrote:quoted
On 21/05/15 06:15PM, Qu Wenruo wrote:quoted
On 2021/5/15 下午5:59, Ritesh Harjani wrote:quoted
On 21/05/15 06:22AM, Qu Wenruo wrote:quoted
quoted
Hi Qu, Thanks for pointing this out. I could see that w/o your new fix I could reproduce the BUG_ON() crash. But with your patch the test btrfs/195 still fails. I guess that is expected right, since "RAID5/6 is not supported yet for sectorsize 4096 with page size 65536"? Is my understanding correct?Yep, the test is still going to fail, as we reject such convert. There are tons of other btrfs tests that fails due to the same reason. Some of them can be avoided using "BTRFS_PROFILE_CONFIGS" environment variant to avoid raid5/6, but not all. Thus I'm going to update those tests to use that variant to make it easier to rule out certain profiles.Hello Qu, Sorry to bother you again. While running your latest full patch series, I found below two failures, no crashes though :) Could you please take a look at it. 1. btrfs/141 failure. xfstests.global-btrfs/4k.btrfs/141 Error Details - output mismatch (see /results/btrfs/results-4k/btrfs/141.out.bad)Strangely, it passes locally.quoted
Standard Output step 1......mkfs.btrfs step 2......corrupt file extent Filesystem type is: 9123683e File size of /vdc/foobar is 131072 (32 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 31: 33632.. 33663: 32: last,eof /vdc/foobar: 1 extent found corrupt stripe #1, devid 2 devpath /dev/vdi physical 116785152 step 3......repair the bad copy Standard Error--- tests/btrfs/141.out 2021-04-24 07:27:39.000000000 +0000 +++ /results/btrfs/results-4k/btrfs/141.out.bad 2021-05-1418:46:23.720000000 +0000@@ -1,37 +1,37 @@QA output created by 141 wrote 131072/131072 bytes XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ +XXXXXXXX: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ read 512/512 bytes XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)The output means the bad copy is not repaired, which is pretty strange. Since my latest work is to make the read repair work in 4K size. Mind to test the attached script? (Of coures, you need to change the $dev and $mnt according to your environment) It would do the same work as btrfs/141, but using scrub to make sure every thing is correct. Locally, I haven't yet hit a failure for btrfs/141 yet.Hello Qu, Sorry about the long delay on this one. I coudn't hit the issue with your test patch on my machine. Also instead of running btrfs/141 standalone when we run it with btrfs/140, the issue is hitting more often. Can you try running below to see if it hits in your case? ./check -I 20 btrfs/140 btrfs/141Awesome! Now I can reproduce it locally too. I'll investigate to ensure it's properly fixed.What a relief, it's not a big problem in my patchset, but more likely to be in the test case, especially in the how the mirror number is chosen. When the test failed, you can find in the dmesg that, there is not any error mssage related to csum mismatch at all. This means, we're reading the correct copy, no wonder we won't submit read repair. This is mostly caused by the page size difference I guess, which makes the pid balance read for RAID1 less perdicatable. I don't yet have any good idea to fix the test case yet, so I'm afraid we have to consider it as a false alert.
Ohk gr8, Thanks a lot for looking into it. I saw the change log of v3, though I don't think there are any changes from when I last tested the whole patch series, still I will give it a full run with v3 for both 4k and 64k config, (since now mostly all issues should be fixed). Thanks -ritesh
Thanks, Ququoted
Thanks again for the awesome report! Ququoted
-riteshquoted
quoted
2. btrfs/124 failure. I guess below could be due to small size of the device? xfstests.global-btrfs/4k.btrfs/124 Error Details - output mismatch (see /results/btrfs/results-4k/btrfs/124.out.bad)Again passes locally. But accroding to your fs, I notice several unbalanced disk usage: # /usr/local/bin/btrfs filesystem show Label: none uuid: fbb48eb6-25c7-4800-8656-503c1e502d85 Total devices 2 FS bytes used 32.00KiB devid 1 size 5.00GiB used 622.38MiB path /dev/vdc devid 2 size 2.00GiB used 622.38MiB path /dev/vdi Label: none uuid: d3c4fb09-eea2-4dea-8187-b13e97f4ad5c Total devices 4 FS bytes used 379.12MiB devid 1 size 5.00GiB used 8.00MiB path /dev/vdb devid 3 size 20.00GiB used 264.00MiB path /dev/vde devid 4 size 20.00GiB used 1.26GiB path /dev/vdf We had reports about btrfs doing poor work when handling unbalanced disk sizes. I had a purpose to fix it, with a little better calcuation, but still not yet perfect. Thus would you mind to check if the test pass when all the disks in SCRATCH_DEV_POOL are in the same size? Of course we need to fix the problem of ENOSPC for unbalanced disks, but that's a common problem and not exacly related to subpage. I should take some time to refresh the unbalanced disk usage patches soon. Thanksm Qu [...]quoted
-ritesh