From: Anshuman Khandual <anshuman.khandual@arm.com>
To: linux-mm@kvack.org, akpm@linux-foundation.org
Cc: hch@infradead.org, christophe.leroy@csgroup.eu,
linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
x86@kernel.org, openrisc@lists.librecores.org,
linux-xtensa@linux-xtensa.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-alpha@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-mips@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-um@lists.infradead.org, linux-sh@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V6 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms
Date: Wed, 6 Jul 2022 11:27:59 +0530 [thread overview]
Message-ID: <8a6ccbae-7d7c-6e08-cc28-eeb649f86112@arm.com> (raw)
In-Reply-To: <20220630051630.1718927-1-anshuman.khandual@arm.com>
On 6/30/22 10:46, Anshuman Khandual wrote:
> __SXXX/__PXXX macros is an unnecessary abstraction layer in creating the
> generic protection_map[] array which is used for vm_get_page_prot(). This
> abstraction layer can be avoided, if the platforms just define the array
> protection_map[] for all possible vm_flags access permission combinations
> and also export vm_get_page_prot() implementation.
>
> This series drops __SXXX/__PXXX macros from across platforms in the tree.
> First it build protects generic protection_map[] array with '#ifdef __P000'
> and moves it inside platforms which enable ARCH_HAS_VM_GET_PAGE_PROT. Later
> this build protects same array with '#ifdef ARCH_HAS_VM_GET_PAGE_PROT' and
> moves inside remaining platforms while enabling ARCH_HAS_VM_GET_PAGE_PROT.
> This adds a new macro DECLARE_VM_GET_PAGE_PROT defining the current generic
> vm_get_page_prot(), in order for it to be reused on platforms that do not
> require custom implementation. Finally, ARCH_HAS_VM_GET_PAGE_PROT can just
> be dropped, as all platforms now define and export vm_get_page_prot(), via
> looking up a private and static protection_map[] array. protection_map[]
> data type has been changed as 'static const' on all platforms that do not
> change it during boot.
>
> This series applies on v5.19-rc4 and has been build tested for multiple
> platforms. While here it has dropped off all previous tags from folks after
> the current restructuring. Series common CC list has been expanded to cover
> all impacted platforms for wider reach.
>
> - Anshuman
>
> Changes in V6:
>
> - Converted protection_map[] array as 'static const' on sparc32 platform
> - Rebased on v5.19-rc4
> - Collected tags
There are two linux-next based build fixes for this series (listed below), when
vm_get_page_prot() gets redefined with !CONFIG_MMU. Platform vm_get_page_prot()
is required only with CONFIG_MMU enabled, otherwise there is a generic fallback
stub in include/linux/mm.h
https://lore.kernel.org/all/20220705221411.3381797-1-jcmvbkbc@gmail.com/ [xtensa]
https://lore.kernel.org/all/20220706054002.1936820-1-anshuman.khandual@arm.com/ [sh]
It does not seem CONFIG_MMU can be disabled on other platforms thus exposing a build
failure. But just to be on the safer side, should all vm_get_page_prot() be wrapped
around with #ifdef CONFIG_MMU ? In that case will resend the series with above build
fixes folded back in as well. Please do suggest. Thank you.
- Anshuman
next prev parent reply other threads:[~2022-07-06 5:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 5:16 [PATCH V6 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 01/26] mm/mmap: Build protect protection_map[] with __P000 Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 02/26] mm/mmap: Define DECLARE_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 03/26] powerpc/mm: Move protection_map[] inside the platform Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 04/26] sparc/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 05/26] arm64/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 06/26] x86/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 07/26] mm/mmap: Build protect protection_map[] with ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 08/26] microblaze/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 09/26] loongarch/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 10/26] openrisc/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 11/26] xtensa/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 12/26] hexagon/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 13/26] parisc/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 14/26] alpha/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 15/26] nios2/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 16/26] riscv/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 17/26] csky/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 18/26] s390/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 19/26] ia64/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 20/26] mips/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 21/26] m68k/mm: " Anshuman Khandual
2022-07-06 10:03 ` Geert Uytterhoeven
2022-07-06 11:15 ` Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 22/26] arc/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 23/26] arm/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 24/26] um/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 25/26] sh/mm: " Anshuman Khandual
2022-06-30 5:16 ` [PATCH V6 26/26] mm/mmap: Drop ARCH_HAS_VM_GET_PAGE_PROT Anshuman Khandual
2022-07-06 10:04 ` Geert Uytterhoeven
2022-07-06 5:57 ` Anshuman Khandual [this message]
2022-07-06 6:33 ` [PATCH V6 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms Christophe Leroy
2022-07-06 7:04 ` Arnd Bergmann
2022-07-06 8:33 ` Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a6ccbae-7d7c-6e08-cc28-eeb649f86112@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=hch@infradead.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=openrisc@lists.librecores.org \
--cc=sparclinux@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).