Re: [PATCH 6.1 00/25] 6.1.1-rc1 review

[Thorsten Leemhuis]

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)