Ext4 data corruption in stable kernels

Posted Dec 10, 2023 9:33 UTC (Sun) by Nemo_bis (guest, #88187)
In reply to: Ext4 data corruption in stable kernels by jalla
Parent article: Ext4 data corruption in stable kernels

Yes, sounds rather similar: from a cursory read of Jan Kara's https://lore.kernel.org/stable/20231205122122.dfhhoaswsfs... , it sounds like a series of changes were tested together in 6.5-rc1 but then only some were backported. So is it an issue of an unstated dependency between commits?

Ext4 data corruption in stable kernels

Posted Dec 10, 2023 9:50 UTC (Sun) by mb (subscriber, #50428) [Link] (4 responses)

>So is it an issue of an unstated dependency between commits?

There should never be such a dependency that corrupts filesystems.
That is very dangerous for git-bisect.

Of course it's not always possible to prevent, if a bug is found later on. But then it's already too late and the commit might have been backported already.

Ext4 data corruption in stable kernels

Posted Dec 10, 2023 13:39 UTC (Sun) by dharding (subscriber, #6509) [Link]

> There should never be such a dependency that corrupts filesystems.
> That is very dangerous for git-bisect.

This is true, but in this case there was not a dependency issue in Linus' tree. The problematic commit (91562895f803) that was backported from the 6.7 series to the stable kernels depended on another commit (936e114a245b6) from the 6.5 series that wasn't backported, which is why the corruption only affects stable kernels containing 91562895f803.

Ext4 data corruption in stable kernels

Posted Dec 10, 2023 15:28 UTC (Sun) by Paf (subscriber, #91811) [Link] (2 responses)

I mean, there shouldn’t be in a patch series, yeah - I think that’s what you’re talking about, a gap in a series where Bad Things happen. But as the other comment notes, this is a much more distant dependency and more “this commit was developed in a context and when ported out of that context, an implicit dependency…” etc, you get it.

Ext4 data corruption in stable kernels

Posted Dec 10, 2023 15:39 UTC (Sun) by mb (subscriber, #50428) [Link] (1 responses)

>an implicit dependency

Was this dependency and its data corruption effects known, when the patch was committed?
It's a nontrivial task to find dependencies and to check the effects if these dependencies are not backported.
After all, any previous commit to the kernel could be such a candidate.

A second problem is: How do we refer to such a dependency? If we want to use the git digest, then there must practically be at least one merge cycle between the commits.

Ext4 data corruption in stable kernels

Posted Dec 11, 2023 14:25 UTC (Mon) by Paf (subscriber, #91811) [Link]

Right, that’s exactly what I was referring to with “developed in the context of” and “you get it”. This problem - of an unknown dependency on an older commit - is not terribly solvable in general. One thing that can help you sometimes is having robust tests.