On Wed, Jan 24, 2024 at 4:34 PM Dan Moulding <dan@xxxxxxxx> 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
