On 21.12.22 07:34, Jiri Slaby wrote: > On 20. 12. 22, 17:11, Guenter Roeck wrote: >> You probably didn't see any reports on mainline because I didn't report >> the issue there yet. There are so many failures in mainline that it is >> a bit difficult to keep up. > > Just heads up, these are breakages in 6.1 known to me: > > an io_uring 32bit test crashes the kernel: > https://lore.kernel.org/all/c80c1e3f-800b-dc49-f2f5-acc8ceb34d51@xxxxxxxxx/ > > Fixed in io_uring tree. Just BTW: afaics the fix is now in mainline as 990a4de57e44 > bind() of previously bound port no longer fails: > https://lore.kernel.org/all/6b971a4e-c7d8-411e-1f92-fda29b5b2fb9@xxxxxxxxxx/ > > No fix available and revert close to impossible. Also just BTW: fix posted yesterday. > And most important, mremap() is broken in 6.1, so mostly everything > fails in some random way: > https://lore.kernel.org/all/20221216163227.24648-1-vbabka@xxxxxxx/T/#u > > Fixed in -mm. That one seems to fix an annoying issue many people might run into (at least it looks like it to my untrained eyes), which is the reason why I write this mail. Andrew moved that fix from mm-hotfixes-unstable to mm-hotfixes-stable yesterday and I assume he'll send it to Linus pretty soon now to ensure it makes it into -rc1, so that the stable team can pick it up. It might be a bad season to ask this, but that made me wonder: Should that patch have progressed quicker? And if so: how to make that happen when a similar situation arises in the future? Should somebody (the developer of the patch? me?) kindly ask the maintainer in question to sent the fix straight to Linus once it spend 1 or 2 days in next? It's not the first time that I see something like this, that's why I'm wondering if I should do something in such situations. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
