linux-kernel - [PATCH 0/2] mm: madvise: make MADV

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-next>] [day] [month] [year] [list]

Message-ID: <cover.1747338438.git.lorenzo.stoakes@oracle.com>
Date: Thu, 15 May 2025 21:15:44 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: James Houghton <jthoughton@...gle.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@...a.com>,
        Yang Shi <yang@...amperecomputing.com>,
        David Hildenbrand <david@...hat.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>, pbonzini@...hat.com,
        kvm@...r.kernel.org, linux-s390@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] mm: madvise: make MADV_NOHUGEPAGE a no-op if !THP

Andrew -

I hope the explanation below resolves your query about the header include
(in [0]), let me know if doing this as a series like this works (we need to
enforce the ordering here).

Thanks!

[0]: 20250514153648.598bb031a2e498b1ac505b60@...ux-foundation.org

Currently, when somebody attempts to set MADV_NOHUGEPAGE on a system that
does not enable CONFIG_TRANSPARENT_HUGEPAGE the confguration option, this
results in an -EINVAL error arising.

This doesn't really make sense, as to do so is essentially a no-op.

Additionally, the semantics of setting VM_[NO]HUGEPAGE in any case are such
that, should the attribute not apply, nothing will be done.

It therefore makes sense to simply make this operation a noop.

However, a fly in the ointment is that, in order to do so, we must check
against the MADV_NOHUGEPAGE constant. In doing so, we encounter two rather
annoying issues.

The first is that the usual include we would import to get hold of
MADV_NOHUGEPAGE, linux/mman.h, results in a circular dependency:

* If something includes linux/mman.h, we in turn include linux/mm.h prior
  to declaring MADV_NOHUGEPAGE.
* This then, in turn, includes linux/huge_mm.h.
* linux/huge_mm.h declares hugepage_madvise(), which then tries to
  reference MADV_NOHUGEPAGE, and the build fails.

This can be reached in other ways too.

So we work around this by including uapi/asm/mman.h instead, which allows
us to keep hugepage_madvise() inline.

The second issue is that the s390 arch declares PROT_NONE as a value in the
enum prot_type enumeration.

By updating the include in linux/huge_mm.h, we pull in the PROT_NONE
declaration (unavoidably, this is ultimately in
uapi/asm-generic/mman-common.h alongside MADV_NOHUGEPAGE), which collides
with the enumeration value.

To resolve this, we rename PROT_NONE to PROT_TYPE_DUMMY.

The ordering of these patches is critical, the s390 patch must be applied
prior to the MADV_NOHUGEPAGE patch, and therefore the two patches are sent
as a series.

v1:
* Place patches in series.
* Correct typo in comment as per James.

previous patches:
huge_mm.h patch - https://lore.kernel.org/all/20250508-madvise-nohugepage-noop-without-thp-v1-1-e7ceffb197f3@kuka.com/
s390 patch - https://lore.kernel.org/all/20250514163530.119582-1-lorenzo.stoakes@oracle.com/

Ignacio Moreno Gonzalez (1):
  mm: madvise: make MADV_NOHUGEPAGE a no-op if !THP

Lorenzo Stoakes (1):
  KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY

 arch/s390/kvm/gaccess.c | 8 ++++----
 include/linux/huge_mm.h | 5 +++++
 2 files changed, 9 insertions(+), 4 deletions(-)

--
2.49.0