linux-kernel - Re: [PATCH v6 21/23] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD

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

Date: Tue, 02 Jul 2024 23:26:19 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Christophe Leroy <christophe.leroy@...roup.eu>, Andrew Morton
 <akpm@...ux-foundation.org>, Jason Gunthorpe <jgg@...dia.com>, Peter Xu
 <peterx@...hat.com>, Oscar Salvador <osalvador@...e.de>, Nicholas Piggin
 <npiggin@...il.com>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v6 21/23] powerpc/64s: Use contiguous PMD/PUD instead of
 HUGEPD

Christophe Leroy <christophe.leroy@...roup.eu> writes:
> On book3s/64, the only user of hugepd is hash in 4k mode.
>
> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>
> Rework hash-4k to use contiguous PMD and PUD instead.
>
> In that setup there are only two huge page sizes: 16M and 16G.
>
> 16M sits at PMD level and 16G at PUD level.
>
> pte_update doesn't know page size, lets use the same trick as
> hpte_need_flush() to get page size from segment properties. That's
> not the most efficient way but let's do that until callers of
> pte_update() provide page size instead of just a huge flag.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
> ---
> v3:
> - Add missing pmd_leaf_size() and pud_leaf_size()
> - More cleanup in hugetlbpage_init()
> - Take a page fault when DIRTY or ACCESSED is missing on hash-4 hugepage
>
> v4: Rebased on v6.10-rc1
>
> v6: Added a WARN_ON_ONCE() in hash__pte_update() in case the pagesize is unexpected.
> ---
>  arch/powerpc/include/asm/book3s/64/hash-4k.h  | 15 ------
>  arch/powerpc/include/asm/book3s/64/hash.h     | 40 +++++++++++++---
>  arch/powerpc/include/asm/book3s/64/hugetlb.h  | 38 ---------------
>  .../include/asm/book3s/64/pgtable-4k.h        | 47 -------------------
>  .../include/asm/book3s/64/pgtable-64k.h       | 20 --------
>  arch/powerpc/include/asm/book3s/64/pgtable.h  | 22 +++++++--
>  arch/powerpc/include/asm/hugetlb.h            |  4 ++
>  .../powerpc/include/asm/nohash/hugetlb-e500.h |  4 --
>  arch/powerpc/include/asm/page.h               |  8 ----
>  arch/powerpc/mm/book3s64/hash_utils.c         | 11 +++--
>  arch/powerpc/mm/book3s64/hugetlbpage.c        | 10 ++++
>  arch/powerpc/mm/book3s64/pgtable.c            | 12 -----
>  arch/powerpc/mm/hugetlbpage.c                 | 26 ----------
>  arch/powerpc/mm/pgtable.c                     |  2 +-
>  arch/powerpc/platforms/Kconfig.cputype        |  1 -
>  15 files changed, 74 insertions(+), 186 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/book3s/64/pgtable-4k.h

This looks good to me. I've run a few tests on it and haven't seen any
issues.

I also dumped the page tables of a test program and checked they looked
sensible. And I checked that the hash insert path is actually inserting
a huge page entry (of course it is, but just to be sure).

On mainline using a hugepd page hits the first warning in
try_grab_folio() (via gup_hugepd()) and hangs the process. I haven't
seen that reported (it goes back to v6.5), so my impression is hugepd on
hash-4k is essentially unused these days.

This series is an improvement on that, so let's get it into mm-unstable
for some wider testing.

Acked-by: Michael Ellerman <mpe@...erman.id.au> (powerpc)

cheers