On 4/8/22 04:50, Andrew Morton wrote: > On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual <anshuman.khandual@xxxxxxx> wrote: > >> protection_map[] is an array based construct that translates given vm_flags >> combination. This array contains page protection map, which is populated by >> the platform via [__S000 .. __S111] and [__P000 .. __P111] exported macros. >> Primary usage for protection_map[] is for vm_get_page_prot(), which is used >> to determine page protection value for a given vm_flags. vm_get_page_prot() >> implementation, could again call platform overrides arch_vm_get_page_prot() >> and arch_filter_pgprot(). Some platforms override protection_map[] that was >> originally built with __SXXX/__PXXX with different runtime values. >> >> Currently there are multiple layers of abstraction i.e __SXXX/__PXXX macros >> , protection_map[], arch_vm_get_page_prot() and arch_filter_pgprot() built >> between the platform and generic MM, finally defining vm_get_page_prot(). >> >> Hence this series proposes to drop later two abstraction levels and instead >> just move the responsibility of defining vm_get_page_prot() to the platform >> (still utilizing generic protection_map[] array) itself making it clean and >> simple. >> >> This first introduces ARCH_HAS_VM_GET_PAGE_PROT which enables the platforms >> to define custom vm_get_page_prot(). This starts converting platforms that >> define the overrides arch_filter_pgprot() or arch_vm_get_page_prot() which >> enables for those constructs to be dropped off completely. >> >> The series has been inspired from an earlier discuss with Christoph Hellwig >> >> https://lore.kernel.org/all/1632712920-8171-1-git-send-email-anshuman.khandual@xxxxxxx/ >> >> This series applies on 5.18-rc1 after the following patch. >> >> https://lore.kernel.org/all/1643004823-16441-1-git-send-email-anshuman.khandual@xxxxxxx/ > > Confusing. That patch is already in 5.18-rc1. Ahh, my bad, forgot to delete these lines here in the cover letter. This series just applies cleanly on 5.18-rc1 without dependency. > But the version which was merged (24e988c7fd1ee701e) lacked the change > to arch/arm64/Kconfig. I seem to recall that this patch went through a > few issues and perhaps the arm64 change was dropped. Can you please > check? ARCH_HAS_FILTER_PGPROT on arm64 got dropped off via another commit i.e 6e2edd6371a4 ("arm64: Ensure execute-only permissions are not allowed without EPAN"). > > (It would be easier for me to track all this down if the original patch > had had cc:linux-mm. Please cc linux-mm! Sure, will do. Please do let me know if there is anything else that needs to be taken care.
