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@e16-tech.com) 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