[Bug 201685] ext4 file system corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #221 from Rainer Fiebig (jrf@xxxxxxxxxxx) ---
#218
If 4.18.20 turns out to be OK, my idea would be to bisect between 4.18 and
4.19.
Jimmy.Jazz has already done that and the result pointed to RCU. But IIRC it was
not a clear cut

> git bisect bad
xyz123 is the first bad commit

With your script we now have a tool to reproduce the problem which makes the
distinction between "good" and "bad" more reliable. And everybody is now also
aware how important it is to ensure that the fs is OK after a bad kernel has
run and that the next step should be done with a known-good kernel. So it
should be possible to identify a bad commit.

Perhaps one could limit the bisect to kernel/rcu or block in a first step. And
if that's inconclusive, extent the search.

But if 4.18.20 is bad, I have no clue at all - at least at the moment.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux