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@gmail.com/
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@kernel.org/
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@suse.cz/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)