lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <918e41dd-e5ea-9dc5-e6d4-5d524f317d18@leemhuis.info>
Date:   Thu, 22 Dec 2022 09:07:21 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        akpm@...ux-foundation.org, Vlastimil Babka <vbabka@...e.cz>
Cc:     stable@...r.kernel.org, patches@...ts.linux.dev,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        shuah@...nel.org, patches@...nelci.org,
        lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
        f.fainelli@...il.com, sudipm.mukherjee@...il.com,
        srw@...dewatkins.net, rwarsow@....de,
        Jiri Slaby <jirislaby@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 6.1 00/25] 6.1.1-rc1 review

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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ