| Message ID | 20220407103251.1209606-1-anshuman.khandual@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm/mmap: Drop arch_vm_get_page_prot() and arch_filter_pgprot() | expand |
On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual <anshuman.khandual@arm.com> 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@arm.com/ > > This series applies on 5.18-rc1 after the following patch. > > https://lore.kernel.org/all/1643004823-16441-1-git-send-email-anshuman.khandual@arm.com/ Confusing. That patch is already in 5.18-rc1. 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? (It would be easier for me to track all this down if the original patch had had cc:linux-mm. Please cc linux-mm!)
On 4/8/22 04:50, Andrew Morton wrote: > On Thu, 7 Apr 2022 16:02:44 +0530 Anshuman Khandual <anshuman.khandual@arm.com> 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@arm.com/ >> >> This series applies on 5.18-rc1 after the following patch. >> >> https://lore.kernel.org/all/1643004823-16441-1-git-send-email-anshuman.khandual@arm.com/ > > 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.