Re: [RFC PATCH 2/3] module: Don't fail module loading when setting ro_after_init section RO failed

[Christophe Leroy]

Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
> On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
> > Once module init has succeded it is too late to cancel loading.
> > If setting ro_after_init data section to read-only fails, all we
> > can do is to inform the user through a warning.
> >
> > Reported-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Closes: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20230915082126.4187913-1-ruanjinjie%40huawei.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C26b5ca7363e54210439b08dd010c4865%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638667874457200373%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZeJ%2F3%2B2Nx%2FBf%2FWLFEkhxKlDhZk8LNkz0fs%2Fg2xMcOjY%3D&reserved=0
> > Fixes: d1909c022173 ("module: Don't ignore errors from set_memory_XX()")
> > Signed-off-by: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
> > ---
> >   kernel/module/main.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 2de4ad7af335..1bf4b0db291b 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -2583,7 +2583,9 @@ static noinline int do_init_module(struct module *mod)
> >   #endif
> >   	ret = module_enable_rodata_ro_after_init(mod);
> >   	if (ret)
> > -		goto fail_mutex_unlock;
> > +		pr_warn("%s: %s() returned %d, ro_after_init data might still be writable\n",
> > +			mod->name, __func__, ret);
> > +
> >   	mod_tree_remove_init(mod);
> >   	module_arch_freeing_init(mod);
> >   	for_class_mod_mem_type(type, init) {
> > @@ -2622,8 +2624,6 @@ static noinline int do_init_module(struct module *mod)
> >   
> >   	return 0;
>
> I think it would make sense to propagate the error. But that would
> require changing modprobe.c. What kind of error can we expect when this
> happens?

AFAIK, on powerpc it fails with EINVAL when
- The area is a vmalloc or module area and is a hugepage area
- The area is not vmalloc or io register and MMU is not powerpc radix MMU

Otherwise it propagates the error from apply_to_existing_page_range(). 
IIUC it will return EINVAL when it hits a leaf PTE in upper directories.

On other architectures it can be different, I know some architecture try 
to split the pages when they hit hugepages and that can fail.


But I believe if it works the first time it should work next time as well.

> >   
> > -fail_mutex_unlock:
> > -	mutex_unlock(&module_mutex);
> >   fail_free_freeinit:
> >   	kfree(freeinit);
> >   fail: