linux-kernel - [PATCH v2 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting

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: <20250107204002.2683356-1-peterx@redhat.com>
Date: Tue,  7 Jan 2025 15:39:55 -0500
From: Peter Xu <peterx@...hat.com>
To: linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Cc: Breno Leitao <leitao@...ian.org>,
	Rik van Riel <riel@...riel.com>,
	Muchun Song <muchun.song@...ux.dev>,
	Naoya Horiguchi <nao.horiguchi@...il.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Ackerley Tng <ackerleytng@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	peterx@...hat.com,
	Oscar Salvador <osalvador@...e.de>
Subject: [PATCH v2 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting

[based on akpm/mm-unstable, latest ca95745c20ad, of Jan 7th 2025]

v2:
- Rebase to latest mm-unstable
- Added R-b and T-b for Ackerley on patch 1

  (Ackerley: I was conservative on the tags here to only attach them in
   patch 1, even though it seems you mentioned you agree/tested with the
   whole series.  Please feel free to provide your tag again on the cover
   letter if you want, thanks)

This is a follow up on Ackerley's series here as replacement:

https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com

The goal of this series is to cleanup hugetlb resv accounting, especially
during folio allocation, to decouple a few things:

  - Hugetlb folios v.s. Hugetlbfs: IOW, the hope is in the future hugetlb
    folios can be allocated completely without hugetlbfs.

  - Decouple VMA v.s. hugetlb folio allocations: allocating a hugetlb folio
    should not always require a hugetlbfs VMA.  For example, either it got
    allocated from the inode level (see hugetlbfs_fallocate() where it used
    a pesudo VMA for allocation), or it can be allocated by other kernel
    subsystems.

It paves way for other users to allocate hugetlb folios out of either
system reservations, or subpools (instead of hugetlbfs, as a file system).
For longer term, this prepares hugetlb as a separate concept versus
hugetlbfs, so that hugetlb folios can be allocated by not only hugetlbfs
and other things.

Tests I've done:

- I had a reproducer in patch 1 for the bug I found, this will start to
  work after patch 1 or the whole set applied.

- Hugetlb regression tests (on x86_64 2MBs), includes:

  - All vmtests on hugetlbfs

  - libhugetlbfs test suite (which may fail some tests, but no new failures
    will be introduced by this series, so all such failures happen before
    this series so shouldn't be relevant).

Comments welcomed, thanks.

Peter Xu (7):
  mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool
  mm/hugetlb: Stop using avoid_reserve flag in fork()
  mm/hugetlb: Rename avoid_reserve to cow_from_owner
  mm/hugetlb: Clean up map/global resv accounting when allocate
  mm/hugetlb: Simplify vma_has_reserves()
  mm/hugetlb: Drop vma_has_reserves()
  mm/hugetlb: Unify restore reserve accounting for new allocations

 fs/hugetlbfs/inode.c    |   2 +-
 include/linux/hugetlb.h |   4 +-
 mm/hugetlb.c            | 237 ++++++++++++++++++----------------------
 3 files changed, 107 insertions(+), 136 deletions(-)

-- 
2.47.0