Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only

[Dave Hansen <dave.hansen@intel.com>]

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?