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

[Linus Torvalds]

On Sat, Feb 11, 2023 at 1:39 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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