[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebbd557e-b31a-0f56-1225-e8940b63d64b@csgroup.eu>
Date: Mon, 27 Jun 2022 05:49:35 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Anshuman Khandual <anshuman.khandual@....com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
CC: "hch@...radead.org" <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"openrisc@...ts.librecores.org" <openrisc@...ts.librecores.org>,
"linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
"linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
"linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V5 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT
Le 27/06/2022 à 06:58, Anshuman Khandual a écrit :
> This just converts the generic vm_get_page_prot() implementation into a new
> macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
> when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create any
> functional change.
>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: linux-mm@...ck.org
> Cc: linux-kernel@...r.kernel.org
> Suggested-by: Christoph Hellwig <hch@...radead.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
Reviewed-by: Christophe Leroy <christophe.leroy@...roup.eu>
> ---
> include/linux/pgtable.h | 28 ++++++++++++++++++++++++++++
> mm/mmap.c | 26 +-------------------------
> 2 files changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 3cdc16cfd867..014ee8f0fbaa 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1689,4 +1689,32 @@ typedef unsigned int pgtbl_mod_mask;
> #define MAX_PTRS_PER_P4D PTRS_PER_P4D
> #endif
>
> +/* description of effects of mapping type and prot in current implementation.
> + * this is due to the limited x86 page protection hardware. The expected
> + * behavior is in parens:
> + *
> + * map_type prot
> + * PROT_NONE PROT_READ PROT_WRITE PROT_EXEC
> + * MAP_SHARED r: (no) no r: (yes) yes r: (no) yes r: (no) yes
> + * w: (no) no w: (no) no w: (yes) yes w: (no) no
> + * x: (no) no x: (no) yes x: (no) yes x: (yes) yes
> + *
> + * MAP_PRIVATE r: (no) no r: (yes) yes r: (no) yes r: (no) yes
> + * w: (no) no w: (no) no w: (copy) copy w: (no) no
> + * x: (no) no x: (no) yes x: (no) yes x: (yes) yes
> + *
> + * On arm64, PROT_EXEC has the following behaviour for both MAP_SHARED and
> + * MAP_PRIVATE (with Enhanced PAN supported):
> + * r: (no) no
> + * w: (no) no
> + * x: (yes) yes
> + */
> +#define DECLARE_VM_GET_PAGE_PROT \
> +pgprot_t vm_get_page_prot(unsigned long vm_flags) \
> +{ \
> + return protection_map[vm_flags & \
> + (VM_READ | VM_WRITE | VM_EXEC | VM_SHARED)]; \
> +} \
> +EXPORT_SYMBOL(vm_get_page_prot);
> +
> #endif /* _LINUX_PGTABLE_H */
> diff --git a/mm/mmap.c b/mm/mmap.c
> index b01f0280bda2..b46d5e931bb3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -81,26 +81,6 @@ static void unmap_region(struct mm_struct *mm,
> struct vm_area_struct *vma, struct vm_area_struct *prev,
> unsigned long start, unsigned long end);
>
> -/* description of effects of mapping type and prot in current implementation.
> - * this is due to the limited x86 page protection hardware. The expected
> - * behavior is in parens:
> - *
> - * map_type prot
> - * PROT_NONE PROT_READ PROT_WRITE PROT_EXEC
> - * MAP_SHARED r: (no) no r: (yes) yes r: (no) yes r: (no) yes
> - * w: (no) no w: (no) no w: (yes) yes w: (no) no
> - * x: (no) no x: (no) yes x: (no) yes x: (yes) yes
> - *
> - * MAP_PRIVATE r: (no) no r: (yes) yes r: (no) yes r: (no) yes
> - * w: (no) no w: (no) no w: (copy) copy w: (no) no
> - * x: (no) no x: (no) yes x: (no) yes x: (yes) yes
> - *
> - * On arm64, PROT_EXEC has the following behaviour for both MAP_SHARED and
> - * MAP_PRIVATE (with Enhanced PAN supported):
> - * r: (no) no
> - * w: (no) no
> - * x: (yes) yes
> - */
> #ifdef __P000
> pgprot_t protection_map[16] __ro_after_init = {
> [VM_NONE] = __P000,
> @@ -123,11 +103,7 @@ pgprot_t protection_map[16] __ro_after_init = {
> #endif
>
> #ifndef CONFIG_ARCH_HAS_VM_GET_PAGE_PROT
> -pgprot_t vm_get_page_prot(unsigned long vm_flags)
> -{
> - return protection_map[vm_flags & (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
> -}
> -EXPORT_SYMBOL(vm_get_page_prot);
> +DECLARE_VM_GET_PAGE_PROT
> #endif /* CONFIG_ARCH_HAS_VM_GET_PAGE_PROT */
>
> static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
Powered by blists - more mailing lists