linux-kernel - Re: [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are disabled

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: <db757c1f-8666-4a73-ab57-cce83059e95d@lucifer.local>
Date: Wed, 25 Jun 2025 08:30:33 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Hugh Dickins <hughd@...gle.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
        ziy@...dia.com, Liam.Howlett@...cle.com, npache@...hat.com,
        ryan.roberts@....com, dev.jain@....com, baohua@...nel.org,
        zokeefe@...gle.com, shy828301@...il.com, usamaarif642@...il.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are
 disabled

On Wed, Jun 25, 2025 at 09:23:31AM +0200, David Hildenbrand wrote:
> Well, one could argue we broke user space (admin settings) when we converted
> "never" to no longer mean "never", but "never by page faults + khugepaged".
> And we did so without updating the documentation.
>
> I finally went back and checked the original discussions and, yes, this was
> deliberate [1].
>
> As so often, we created a mess with THP toggles.

I mean... !!!

>
> Probably best to fixup the "never" documentation, and state that there is no
> way to disable MADV_COLLAPSE anymore.

I disagree on the basis that system administrators will absolutely expect:

# echo never > /sys/kernel/mm/transparent-hugepage/enabled

To disable THP.

I _guarantee_ you that's what nearly everybody except a handful of people will
expect.

If we do decide to not do this series, _please_ can we seriously update the
documentation to be _absolutely crystal clear_ about this.

I will volunteer to do this in this case :)

>
> I agree that if we want a way to disable all of them, we better have a
> "deny" now. ... until someone else breaks that, then we can have a
> "really_never_deny_all" etc. ;)

I really really dislike this. 'Deny' is weaker than 'never'. And now we have to
add even more complexity to the thing.

Sorry but with 'never' we basically chose the strongest possible term.

It would have to be something really horrid like 'never_even_collapse'.

I want to throw up...