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 <[email protected]>
>> > Suggested-by: Gary Guo <[email protected]>
>>
>> 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
