Re: [PATCH V6 00/26] mm/mmap: Drop __SXXX/__PXXX macros from across platforms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Le 06/07/2022 à 07:57, Anshuman Khandual a écrit :


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@xxxxxxxxx/	[xtensa]
https://lore.kernel.org/all/20220706054002.1936820-1-anshuman.khandual@xxxxxxx/ [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.


As far as I can see in Kconfig, CONFIG_MMU is user selectable on the 
following architectures:
- ARM
- M68K
- RISCV
- SH

And is disabled by default on XTENSA.

So I guess ARM, M68K, RISCV, SH and XTENSA should have it wrapped around 
#ifdef CONFIG_MMU , or have it in a file that is not built when 
CONFIG_MMU is not set.

Christophe




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux