On Tue, Jan 23, 2024 at 02:35:15PM -0700, Dan Moulding wrote:
Or is the regression also in Linus's tree and both of these should be reverted/dropped in order to keep systems ok until the bug is fixed in Linus's tree?
The regression is in Linus' tree and appeared with commit bed9e27baf52. I was operating under the assumption that the two commits (bed9e27baf52 and d6e035aad6c0) are intended to exist as a pair that should go together (the commit messages led me to believe so).
The commit that caused the regression has already appeared in the 6.7.1 release (but without the second commit). Since I thought the two commits are a pair and the regression needs to be reverted, that the second commit should not be backported for 6.7.2 until the issue is properly resolved in Linus' tree.
But it sounds like Song Liu is saying that the second commit (d6e035aad6c0) should actually be fine to accept on its own even though the other one needs to be reverted, and is not really dependent on the one that caused the regression [1]. So maybe it's fine to pick it up for 6.7.2.
I can say that I have tested 6.7.1 plus just commit d6e035aad6c0 and I cannot reproduce the regression with it. But 6.7.1 plus both commits, I can still reproduce the regression. So bed9e27baf52 definitely needs to be reverted to eliminate the regression.
I hope that clears things up some.
Nope, not at all :)
For now, I'm going to keep both commits in the stable trees, as that matches what is in Linus's tree as this seems to be hard to reproduce and I haven't seen any other reports of issues. Being in sync with what is in Linus's tree is almost always good, that way if a fix happens there, we can easily backport it to the stable trees too.
So unless the maintainer(s) say otherwise, I'll just let this be.
thanks,
greg k-h