Ext4 data corruption in stable kernels
Ext4 data corruption in stable kernels
Posted Dec 10, 2023 9:50 UTC (Sun) by mb (subscriber, #50428)In reply to: Ext4 data corruption in stable kernels by Nemo_bis
Parent article: Ext4 data corruption in stable kernels
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.
Posted Dec 10, 2023 13:39 UTC (Sun)
by dharding (subscriber, #6509)
[Link]
Posted Dec 10, 2023 15:28 UTC (Sun)
by Paf (subscriber, #91811)
[Link] (2 responses)
Posted Dec 10, 2023 15:39 UTC (Sun)
by mb (subscriber, #50428)
[Link] (1 responses)
Was this dependency and its data corruption effects known, when the patch was committed?
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.
Posted Dec 11, 2023 14:25 UTC (Mon)
by Paf (subscriber, #91811)
[Link]
> There should never be such a dependency that corrupts filesystems.Ext4 data corruption in stable kernels
> 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
Ext4 data corruption in stable kernels
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.
Ext4 data corruption in stable kernels