On 2/28/22 4:27 PM, Russell King (Oracle) wrote:
On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote:
This defines and exports a platform specific custom vm_get_page_prot() via
subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX
macros can be dropped which are no longer needed.
What I would really like to know is why having to run _code_ to work out
what the page protections need to be is better than looking it up in a
table.
Not only is this more expensive in terms of CPU cycles, it also brings
additional code size with it.
I'm struggling to see what the benefit is.
Currently vm_get_page_prot() is also being _run_ to fetch required page
protection values. Although that is being run in the core MM and from a
platform perspective __SXXX, __PXXX are just being exported for a table.
Looking it up in a table (and applying more constructs there after) is
not much different than a clean switch case statement in terms of CPU
usage. So this is not more expensive in terms of CPU cycles.
--------------------------
pgprot_t protection_map[16] __ro_after_init = {
__P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111,
__S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
};
#ifndef CONFIG_ARCH_HAS_FILTER_PGPROT
static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
{
return prot;
}
#endif
pgprot_t vm_get_page_prot(unsigned long vm_flags)
{
pgprot_t ret = __pgprot(pgprot_val(protection_map[vm_flags &
(VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
pgprot_val(arch_vm_get_page_prot(vm_flags)));
return arch_filter_pgprot(ret);
}
EXPORT_SYMBOL(vm_get_page_prot)
----------------------------
There will be a single vm_get_page_prot() instance on a given platform
just like before. So this also does not bring any additional code size
with it.
As mentioned earlier on a previous version.
Remove multiple 'core MM <--> platform' abstraction layers to map
vm_flags access permission combination into page protection.
