[RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
Dave Hansen
dave.hansen at intel.com
Tue Jun 9 12:33:36 PDT 2026
On 6/9/26 07:37, Xueyuan Chen wrote:
> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
> +{
> + return false;
> +}
This is a rather wonky function. It's going to cause all kinds of fun if
it is used like this:
arch_make_pages_readonly(syscall_table, 1);
It's also kinda weird to have it return a bool, and not check that bool
at the single call site. Some things come to mind:
1. This function needs commenting. It needs to say what it does, when
architectures should override it and what their implementations
should look like. It needs to be clear that this can't be used for
anything really important. What should architectures do with alias
mappings? Are they allowed to touch non-direct map aliases? Are they
required to?
2. The return type needs to be reconsidered. Is 'bool' even acceptable?
Should it just be 'void' if callers can't do anything when it fails?
3. What should the naming be? "readonly" vs "ro". Should it have a
"maybe" since it's kinda optional?
4. Should this new API be folio or page-based in the first place?
5. Is mm/huge_memory.c the right place to define a generic mm function,
even a stub?
More information about the linux-arm-kernel
mailing list