Hi, xfstest btrfs/158 trigged a panic after these 2 patches are applied. btrfs-158-dmesg.txt dmesg output when panic btrfs-158-dmesg-decoded.txt dmesg output decoded by decode_stacktrace.sh and some source code is added too. reproduce rate: not 100%, but 2 times here. xfstest './check -g scrub' seem higher rate than './check test/btrfs/158' to reproduce this problem . linux kernel: 5.15.59 with some local backport patches too. Best Regards Wang Yugui (wangyugui@xxxxxxxxxxxx) 2022/08/04 > Hi Greg and Sasha, > > This two patches are backports for v5.15 and v5.10 (for v5.10 conflicts > can be auto resolved) stable branches. > > (For older branches from v4.9 to v5.4, due to some naming change, > although the patches can be applied with auto-resolve, they won't compile). > > These two patches are reducing the chance of destructive RMW cycle, > where btrfs can use corrupted data to generate new P/Q, thus making some > repairable data unrepairable. > > Those patches are more important than what I initially thought, thus > unfortunately they are not CCed to stable by themselves. > > Furthermore due to recent refactors/renames, there are quite some member > change related to those patches, thus have to be manually backported. > > > One of the fastest way to verify the behavior is the existing btrfs/125 > test case from fstests. (not in auto group AFAIK). > > Qu Wenruo (2): > btrfs: only write the sectors in the vertical stripe which has data > stripes > btrfs: raid56: don't trust any cached sector in > __raid56_parity_recover() > > fs/btrfs/raid56.c | 74 ++++++++++++++++++++++++++++++++++++----------- > 1 file changed, 57 insertions(+), 17 deletions(-) > > -- > 2.37.0
Attachment:
btrfs-158-dmesg.txt
Description: Binary data
Attachment:
btrfs-158-dmesg-decoded.txt
Description: Binary data
