linux-ext4 - [Bug 201685] ext4 file system corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-201685-13602-UO7tSXVeqF@https.bugzilla.kernel.org/>
Date:   Tue, 04 Dec 2018 10:16:39 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

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

--- Comment #221 from Rainer Fiebig (jrf@...lbox.org) ---
#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.