On 2023-05-24 at 07:52:59 +1000, Dave Chinner wrote: > On Tue, May 23, 2023 at 05:14:24PM +0800, Pengfei Xu wrote: > > I did not do well in two points, which led to the problem of this useless > > bisect info: > > 1. Should double check "V4 Filesystem" related issue carefully, and should > > give reason of problem. > > 2. Double check the bisect bad and good dmesg info, this time actually > > "good(actually not good)" dmesg also contains "BUG" related > > dmesg, but it doesn't contain the keyword "xfs_extent_free_diff_items" > > dmesg info, and give the wrong bisect info. > > Sorry for inconvenience... > > I think you misunderstand. > > The bisect you did was correct - the commit it > identified was certainly does expose the underlying issue. > > The reason the bisect, while correct, is actually useless is that it > the underlying issue that the commit tripped over is not caused by > the change in the commit. The underlying issue has been there for a > long while - probably a decade - and it's that old, underlying issue > that has caused the new code to fail. > > IOWs, the problem is not the new code (i.e. it is not a regression > in the new code identified by the bisect), the problem is in other > code that has been silently propagating undetected corruption for > years. Hence the bisect is not actually useful in diagnosing the > root cause of the problem. > Thanks a lot Dave's description! It's clear. Anyway I will remove "CONFIG_XFS_SUPPORT_V4" in syzkaller fuzzing test next time to avoid the noise. Thanks also to Eric Biggers, Bagas Sanjaya and all community's help! Thanks! BR. > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
