linux-kernel - Re: [PATCH v5 0/8] huge vmalloc mappings

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

Date:   Fri, 21 Aug 2020 07:47:57 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Nicholas Piggin <npiggin@...il.com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        Zefan Li <lizefan@...wei.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v5 0/8] huge vmalloc mappings



Le 21/08/2020 à 06:44, Nicholas Piggin a écrit :
> I made this powerpc-only for the time being. It shouldn't be too hard to
> add support for other archs that define HUGE_VMAP. I have booted x86
> with it enabled, just may not have audited everything.

I like this series, but if I understand correctly it enables huge 
vmalloc mappings only for hugepages sizes matching a page directory 
levels, ie on a PPC32 it would work only for 4M hugepages.

On the 8xx, we only have 8M and 512k hugepages. Any change that it can 
support these as well one day ?

Christophe

> 
> Hi Andrew, would you care to put this in your tree?
> 
> Thanks,
> Nick
> 
> Since v4:
> - Fixed an off-by-page-order bug in v4
> - Several minor cleanups.
> - Added page order to /proc/vmallocinfo
> - Added hugepage to alloc_large_system_hage output.
> - Made an architecture config option, powerpc only for now.
> 
> Since v3:
> - Fixed an off-by-one bug in a loop
> - Fix !CONFIG_HAVE_ARCH_HUGE_VMAP build fail
> - Hopefully this time fix the arm64 vmap stack bug, thanks Jonathan
>    Cameron for debugging the cause of this (hopefully).
> 
> Since v2:
> - Rebased on vmalloc cleanups, split series into simpler pieces.
> - Fixed several compile errors and warnings
> - Keep the page array and accounting in small page units because
>    struct vm_struct is an interface (this should fix x86 vmap stack debug
>    assert). [Thanks Zefan]
> 
> Nicholas Piggin (8):
>    mm/vmalloc: fix vmalloc_to_page for huge vmap mappings
>    mm: apply_to_pte_range warn and fail if a large pte is encountered
>    mm/vmalloc: rename vmap_*_range vmap_pages_*_range
>    lib/ioremap: rename ioremap_*_range to vmap_*_range
>    mm: HUGE_VMAP arch support cleanup
>    mm: Move vmap_range from lib/ioremap.c to mm/vmalloc.c
>    mm/vmalloc: add vmap_range_noflush variant
>    mm/vmalloc: Hugepage vmalloc mappings
> 
>   .../admin-guide/kernel-parameters.txt         |   2 +
>   arch/Kconfig                                  |   4 +
>   arch/arm64/mm/mmu.c                           |  12 +-
>   arch/powerpc/Kconfig                          |   1 +
>   arch/powerpc/mm/book3s64/radix_pgtable.c      |  10 +-
>   arch/x86/mm/ioremap.c                         |  12 +-
>   include/linux/io.h                            |   9 -
>   include/linux/vmalloc.h                       |  13 +
>   init/main.c                                   |   1 -
>   mm/ioremap.c                                  | 231 +--------
>   mm/memory.c                                   |  60 ++-
>   mm/page_alloc.c                               |   4 +-
>   mm/vmalloc.c                                  | 456 +++++++++++++++---
>   13 files changed, 476 insertions(+), 339 deletions(-)
>