Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()

["Gary Guo" <gary@garyguo.net>]

On Tue Apr 28, 2026 at 1:37 AM BST, Shashank Balaji wrote:
> Hi Gary,
>
> On Mon, Apr 27, 2026 at 02:29:55PM +0100, Gary Guo wrote:
>> On Mon Apr 27, 2026 at 3:41 AM BST, Shashank Balaji wrote:
>> > module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
>> > of platform drivers register themselves prior to subsys_initcalls
>> > (tegra194_cbb_driver registers in a pure_initcall, for example). With an
>> > upcoming patch ("driver core: platform: set mod_name in driver registration")
>> > that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
>> > will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
>> > This causes a null deref because module_kset isn't alive yet.
>> >
>> > Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
>> > Modernize the pr_warn while we're at it.
>> >
>> > Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > Suggested-by: Gary Guo <gary@garyguo.net>
>> 
>> I didn't suggest this change :)
>> 
>> I suggested `pure_initcall`, which is just a one line change.
>
> Oops, sorry about the misattribution.
>
>> diff --git a/kernel/params.c b/kernel/params.c
>> index 74d620bc2521..ac088d4b09a9 100644
>> --- a/kernel/params.c
>> +++ b/kernel/params.c
>> @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
>>  
>>  	return 0;
>>  }
>> -subsys_initcall(param_sysfs_init);
>> +pure_initcall(param_sysfs_init);
>>  
>>  /*
>>   * param_sysfs_builtin_init - add sysfs version and parameter
>> 
>> pure_initcall is level 0 so it happens before all other init calls. Does it not
>> work?
>
> tegra194_cbb_driver registers itself in a pure_initcall too. We wouldn't
> want the ordering of its registration and module_kset init to be link order
> dependent.

It's the only device driver that does this. And I don't think it's supposed to.

From documentation:

> A "pure" initcall has no dependencies on anything else, and purely
> initializes variables that couldn't be statically initialized.

I understand that given large amount of drivers registering themselves during
core/arch_initcall that there might be regressions if all of them are moved, but
surely we can demote these two specific tegra driver to core/postcore_initcall?
This will still be called earlier than init_machine call which happens during
arch_initcall.

Looks like the tegra CBB driver is just doing error logging anyway.

Best,
Gary