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
