linux-kernel - [PATCH v1 0/5] mm/rmap: separate hugetlb rmap handling

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: <20231128145205.215026-1-david@redhat.com>
Date:   Tue, 28 Nov 2023 15:52:00 +0100
From:   David Hildenbrand <david@...hat.com>
To:     linux-kernel@...r.kernel.org
Cc:     linux-mm@...ck.org, David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <muchun.song@...ux.dev>
Subject: [PATCH v1 0/5] mm/rmap: separate hugetlb rmap handling

Let's just cleanly separate hugetlb rmap handling from "ordinary" rmap
handling, like we already do when adding anon hugetlb folios. We have
hugetlb special-casing/checks in the callers in all cases either way
already in place: it doesn't make too much sense to call generic-looking
functions that end up doing hugetlb specific things from hugetlb
special-cases.

This now also means that we won't run into "folio_test_pmd_mappable()"
cases for hugetlb, which doesn't make too much sense with gigantic hugetlb
folios that are in fact currently only PUD-mappable. Or having a
folio_add_file_rmap() function that looks like it clould be used by hugetlb
code, but really can't.

This is a stanalone cleanup, but it gets more relevant when adding more
rmap batching (we cannot map parts of a hugetlb folio) or changing the way
we handle partially-mappable folios as in [1], whereby we'd have to add
more hugetlb special casing to keep hugetlb working as is.

If ever something about hugetlb changes that makes them actually
partially-mappable folios, we can look into cleanly merging all code
paths, not just some.

[1] https://lkml.kernel.org/r/20231124132626.235350-1-david@redhat.com

Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mike Kravetz <mike.kravetz@...cle.com>
Cc: Muchun Song <muchun.song@...ux.dev>

David Hildenbrand (5):
  mm/rmap: rename hugepage_add* to hugetlb_add*
  mm/rmap: introduce and use hugetlb_remove_rmap()
  mm/rmap: introduce and use hugetlb_add_file_rmap()
  mm/rmap: introduce and use hugetlb_try_dup_anon_rmap()
  mm/rmap: add hugetlb sanity checks

 include/linux/mm.h   | 12 +++++++++---
 include/linux/rmap.h | 37 +++++++++++++++++++++++++++++++++++--
 mm/hugetlb.c         | 21 ++++++++++-----------
 mm/migrate.c         |  6 +++---
 mm/rmap.c            | 31 ++++++++++++++++++-------------
 5 files changed, 75 insertions(+), 32 deletions(-)

base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
-- 
2.41.0