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

[Christophe Leroy <christophe.leroy@csgroup.eu>]

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@linutronix.de>
>> 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@csgroup.eu>
>> ---
>>   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:
>