On Wed, Jan 24, 2024 at 4:34 PM Dan Moulding dan@danm.net wrote:
For now, I'm going to keep both commits in the stable trees, as that matches what is in Linus's tree
Please consider reverting bed9e27baf52 in both Linus' tree and the stable trees. That would keep them in sync while keeping this new regression out of the kernel.
as this seems to be hard to reproduce and I haven't seen any other reports of issues.
The change that caused the regression itself purports to fix a two-year old regression. But since that alleged regression has been in the kernel for two years, seemingly without much (if any) public complaint, I'd say that the new regression caused by bed9e27baf52 is definitely the easier one to reproduce (I hit it within hours after upgrading to 6.7.1).
Agreed. I am thinking about reverting bed9e27baf52.
I've also reproduced this regression in a fresh Fedora 39 VM that I just spun up to try to reproduce it in a different environment. I can reproduce it both with the vanilla stable v6.6.13 sources as well as with the distribution kernel (6.6.13-200-fc39.x86_64). Song, I'm happy to provide the details of how I built this VM, or even the VM's libvirt XML and disk images, if that would help with your efforts to reproduce the problem.
Repro steps in vm setup will be really helpful. I think I just need the commands that set up the array for now. If that doesn't work, we can try the disk image.
Thanks, Song