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

[based on akpm/mm-unstable, latest 8351c1503010, of Dec 1st 2024]

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

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

Ackerley, I wanted to reuse some of your patches, but when looking at this
issue I found a bug which is described in patch 1. I'll need to have that
patch to be the 1st patch of the series, and then I also found this is so
far the best way to layout this whole set.  It should have gone a bit
further than what you tried to do in your series, but I assume many of your
gmem 1G patches after that will still apply on top.

The goal of this series is to cleanup hugetlb resv accounting, especially
during folio allocation.  It paves way for other users to allocate hugetlb
folios out of either system reservations, or subpools (instead of
hugetlbfs, as a file system).  So for the longer term, maybe there's chance
to use hugetlb to be separate concept v.s. hugetlbfs, which I hope would
work.

Going back to this small (not so much..) refactoring series.  It touches
the (probably.. hard to read for most) hugetlb resv code, try to make it
more readable, decouple things so that it might be easier in the future to
allocate the folios without hugetlb VMAs.

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

Note that I found libhugetlbfs test suites can fail on some of the tests,
but it doesn't look like to be caused by this series, as I can get the same
results when I run the test suites on either akpm/mm-stable or v6.12 tag.
I didn't yet have time to look into all the issues, but the current guess
is those issues are separate from this series.

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            | 243 ++++++++++++++++++----------------------
 3 files changed, 110 insertions(+), 139 deletions(-)

-- 
2.47.0