linux-kernel - Re: Linux regressions report for mainline [2023-02-11]

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]

Date:   Sat, 11 Feb 2023 14:31:53 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Regzbot (on behalf of Thorsten Leemhuis)" 
        <regressions@...mhuis.info>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Chen <david.chen@...anix.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-02-11]

On Sat, Feb 11, 2023 at 1:39 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Or even just reverting the original commit e320d3012d25
> ("mm/page_alloc.c: fix freeing non-compound pages") and say that the
> (very rare) memory leak is much less dangerous than that hacky fix
> (that was buggy).
>
> Because it's a bit dodgy how commit e320d3012d25 ends up hooking into
> __free_pages(),

Actually, that's not the only dodgy thing about it.

It assumes that any multi-order page allocator user doesn't use the
page counts and only ever has a single "alloc" and a "free".

And apparently that assumption is correct, or we'd have seen a lot of problems.

But it *also* assumes that the speculative page alloc/free was for one
single page, and while that used to be true, the whole higher-order
folio code means that it's not necessarily true any more.

Or rather, I guess it *is* true in practice, but if you ever want to
enable 16kB folios on some filesystem, that commit e320d3012d25 is
just plain unfixably buggy.

Are we there yet? Clearly not, considering bugs like this. But it all
does make me go "Hmm, maybe we'd be better off with the outright
revert and accept the unlikely memory leak for now".

Willy?

               Linus