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

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

[Shashank Balaji]

Adding Tegra maintainers.

On Tue, Apr 28, 2026 at 12:10:50PM +0100, Gary Guo wrote:
> 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.

That's a good point, Gary. Thanks!

Hi Thierry and Jonathan,

You can find the context for this email in this patch:
https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/

TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
registering themselves as early as in a pure_initcall. This is a problem
on two fronts:
1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
initialize variables that couldn't be statically initialized. But these
are doing driver registrations.
2. module_kset not initialized at pure_initcall stage: This is needed to
set the module sysfs symlink. Since module_kset is not alive yet during
pure_initcalls, registering these drivers panics the kernel.

We would like to do the tegra cbb driver registration in a core_initcall
(or some later initcall works too), and move module_kset initialization
to a pure_initcall. Like this:

diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
index ab75d50cc85c..2f69e104c838 100644
--- a/drivers/soc/tegra/cbb/tegra194-cbb.c
+++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
@@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
 {
        return platform_driver_register(&tegra194_cbb_driver);
 }
-pure_initcall(tegra194_cbb_init);
+core_initcall(tegra194_cbb_init);

 static void __exit tegra194_cbb_exit(void)
 {
diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
index fb26f085f691..785072fa4e85 100644
--- a/drivers/soc/tegra/cbb/tegra234-cbb.c
+++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
@@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
 {
        return platform_driver_register(&tegra234_cbb_driver);
 }
-pure_initcall(tegra234_cbb_init);
+core_initcall(tegra234_cbb_init);

 static void __exit tegra234_cbb_exit(void)
 {

Would this work?

Thanks,
Shashank

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

[Shashank Balaji]

Hi Thierry, Jonathan,

Just following up on the below, would moving tegra194_cbb_driver and
tegra234_cbb_driver from pure_initcall to core_initcall work for you?

Thanks,
Shashank

On Tue, Apr 28, 2026 at 10:07:41PM +0900, Shashank Balaji wrote:
> Adding Tegra maintainers.
> 
> On Tue, Apr 28, 2026 at 12:10:50PM +0100, Gary Guo wrote:
> > 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.
> 
> That's a good point, Gary. Thanks!
> 
> Hi Thierry and Jonathan,
> 
> You can find the context for this email in this patch:
> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
> 
> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
> registering themselves as early as in a pure_initcall. This is a problem
> on two fronts:
> 1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
> initialize variables that couldn't be statically initialized. But these
> are doing driver registrations.
> 2. module_kset not initialized at pure_initcall stage: This is needed to
> set the module sysfs symlink. Since module_kset is not alive yet during
> pure_initcalls, registering these drivers panics the kernel.
> 
> We would like to do the tegra cbb driver registration in a core_initcall
> (or some later initcall works too), and move module_kset initialization
> to a pure_initcall. Like this:
> 
> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
> index ab75d50cc85c..2f69e104c838 100644
> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
>  {
>         return platform_driver_register(&tegra194_cbb_driver);
>  }
> -pure_initcall(tegra194_cbb_init);
> +core_initcall(tegra194_cbb_init);
> 
>  static void __exit tegra194_cbb_exit(void)
>  {
> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
> index fb26f085f691..785072fa4e85 100644
> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
>  {
>         return platform_driver_register(&tegra234_cbb_driver);
>  }
> -pure_initcall(tegra234_cbb_init);
> +core_initcall(tegra234_cbb_init);
> 
>  static void __exit tegra234_cbb_exit(void)
>  {
> 
> Would this work?
> 
> Thanks,
> Shashank
> 

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

[Jon Hunter]

Hi Shashank,

On 12/05/2026 03:12, Shashank Balaji wrote:

...

>> Hi Thierry and Jonathan,
>>
>> You can find the context for this email in this patch:
>> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
>>
>> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
>> registering themselves as early as in a pure_initcall. This is a problem
>> on two fronts:
>> 1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
>> initialize variables that couldn't be statically initialized. But these
>> are doing driver registrations.
>> 2. module_kset not initialized at pure_initcall stage: This is needed to
>> set the module sysfs symlink. Since module_kset is not alive yet during
>> pure_initcalls, registering these drivers panics the kernel.

Where exactly is this panic seen? Ie. why are we not seeing this?

>> We would like to do the tegra cbb driver registration in a core_initcall
>> (or some later initcall works too), and move module_kset initialization
>> to a pure_initcall. Like this:
>>
>> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
>> index ab75d50cc85c..2f69e104c838 100644
>> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
>> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
>> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
>>   {
>>          return platform_driver_register(&tegra194_cbb_driver);
>>   }
>> -pure_initcall(tegra194_cbb_init);
>> +core_initcall(tegra194_cbb_init);
>>
>>   static void __exit tegra194_cbb_exit(void)
>>   {
>> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
>> index fb26f085f691..785072fa4e85 100644
>> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
>> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
>> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
>>   {
>>          return platform_driver_register(&tegra234_cbb_driver);
>>   }
>> -pure_initcall(tegra234_cbb_init);
>> +core_initcall(tegra234_cbb_init);
>>
>>   static void __exit tegra234_cbb_exit(void)
>>   {
>>
>> Would this work?


I am adding Sumit who has been doing a lot of the Tegra CBB driver work.

Sumit, any concerns here? We could run this change through our internal 
testing to confirm.

Jon

-- 
nvpublic

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

[Sumit Gupta]

On 12/05/26 14:25, Jon Hunter wrote:
> Hi Shashank,
>
> On 12/05/2026 03:12, Shashank Balaji wrote:
>
> ...
>
>>> Hi Thierry and Jonathan,
>>>
>>> You can find the context for this email in this patch:
>>> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/ 
>>>
>>>
>>> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
>>> registering themselves as early as in a pure_initcall. This is a 
>>> problem
>>> on two fronts:
>>> 1. Philosophical: As Gary pointed out, pure_initcalls are intended 
>>> to purely
>>> initialize variables that couldn't be statically initialized. But these
>>> are doing driver registrations.
>>> 2. module_kset not initialized at pure_initcall stage: This is 
>>> needed to
>>> set the module sysfs symlink. Since module_kset is not alive yet during
>>> pure_initcalls, registering these drivers panics the kernel.
>
> Where exactly is this panic seen? Ie. why are we not seeing this?
>
>>> We would like to do the tegra cbb driver registration in a 
>>> core_initcall
>>> (or some later initcall works too), and move module_kset initialization
>>> to a pure_initcall. Like this:
>>>
>>> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c 
>>> b/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> index ab75d50cc85c..2f69e104c838 100644
>>> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
>>> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
>>>   {
>>>          return platform_driver_register(&tegra194_cbb_driver);
>>>   }
>>> -pure_initcall(tegra194_cbb_init);
>>> +core_initcall(tegra194_cbb_init);
>>>
>>>   static void __exit tegra194_cbb_exit(void)
>>>   {
>>> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c 
>>> b/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> index fb26f085f691..785072fa4e85 100644
>>> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
>>> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
>>>   {
>>>          return platform_driver_register(&tegra234_cbb_driver);
>>>   }
>>> -pure_initcall(tegra234_cbb_init);
>>> +core_initcall(tegra234_cbb_init);
>>>
>>>   static void __exit tegra234_cbb_exit(void)
>>>   {
>>>
>>> Would this work?
>
>
> I am adding Sumit who has been doing a lot of the Tegra CBB driver work.
>
> Sumit, any concerns here? We could run this change through our 
> internal testing to confirm.
>
> Jon
>

CBB driver can be switched to core_initcall.
pure_initcall was originally added so its IRQ handler is registered
before other Tegra drivers to catch and print any bad MMIO error
during their probe.
Looked at the current state of Tegra drivers:
  - The other early Tegra drivers (PMC, fuse, flowctrl, ARI) all run at
    early_initcall, before either pure_ or core_initcall.
  - The only other Tegra core_initcall is tegra-hsp, and link order keeps
    CBB ahead of it (drivers/soc/ links before drivers/mailbox/).

Acked-by: Sumit Gupta <sumitg@nvidia.com>

Thank you,
Sumit Gupta

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

[Shashank Balaji]

On Tue, May 12, 2026 at 05:44:40PM +0530, Sumit Gupta wrote:
> 
> On 12/05/26 14:25, Jon Hunter wrote:
> > Hi Shashank,
> > 
> > On 12/05/2026 03:12, Shashank Balaji wrote:
> > 
> > ...
> > 
> > > > Hi Thierry and Jonathan,
> > > > 
> > > > You can find the context for this email in this patch:
> > > > https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
> > > > 
> > > > 
> > > > TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
> > > > registering themselves as early as in a pure_initcall. This is a
> > > > problem
> > > > on two fronts:
> > > > 1. Philosophical: As Gary pointed out, pure_initcalls are
> > > > intended to purely
> > > > initialize variables that couldn't be statically initialized. But these
> > > > are doing driver registrations.
> > > > 2. module_kset not initialized at pure_initcall stage: This is
> > > > needed to
> > > > set the module sysfs symlink. Since module_kset is not alive yet during
> > > > pure_initcalls, registering these drivers panics the kernel.
> > 
> > Where exactly is this panic seen? Ie. why are we not seeing this?

The panic happens as a result of this patch series. This series aims to
set .mod_name of struct device_driver for platform drivers. So that, for
built-in drivers, their module sysfs symlink can be created on the basis
of .modname. We essentially want to link a platform driver to its
module. This happens naturally if the driver is built as a loadable
module, but for this to happen for built-in modules, .mod_name needs to be set.

To go from .mod_name to the module sysfs symlink, the module_kset kset
needs to be initialized. This currently happens in a subsys_initcall.
These tegra cbb drivers register themselves in a pure_initcall, i.e.
before subsys_initcall, leading to a null dereference of module_kset.

To fix this, we want to move the module_kset creation to pure_initcall,
and tegra cbb driver registration to core_initcall, so after
pure_initcall.

> > > > We would like to do the tegra cbb driver registration in a
> > > > core_initcall
> > > > (or some later initcall works too), and move module_kset initialization
> > > > to a pure_initcall. Like this:
> > > > 
> > > > diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > b/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > index ab75d50cc85c..2f69e104c838 100644
> > > > --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
> > > > @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
> > > >   {
> > > >          return platform_driver_register(&tegra194_cbb_driver);
> > > >   }
> > > > -pure_initcall(tegra194_cbb_init);
> > > > +core_initcall(tegra194_cbb_init);
> > > > 
> > > >   static void __exit tegra194_cbb_exit(void)
> > > >   {
> > > > diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > b/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > index fb26f085f691..785072fa4e85 100644
> > > > --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
> > > > @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
> > > >   {
> > > >          return platform_driver_register(&tegra234_cbb_driver);
> > > >   }
> > > > -pure_initcall(tegra234_cbb_init);
> > > > +core_initcall(tegra234_cbb_init);
> > > > 
> > > >   static void __exit tegra234_cbb_exit(void)
> > > >   {
> > > > 
> > > > Would this work?
> > 
> > 
> > I am adding Sumit who has been doing a lot of the Tegra CBB driver work.
> > 
> > Sumit, any concerns here? We could run this change through our internal
> > testing to confirm.
> > 
> > Jon
> > 
> 
> CBB driver can be switched to core_initcall.
> pure_initcall was originally added so its IRQ handler is registered
> before other Tegra drivers to catch and print any bad MMIO error
> during their probe.
> Looked at the current state of Tegra drivers:
>  - The other early Tegra drivers (PMC, fuse, flowctrl, ARI) all run at
>    early_initcall, before either pure_ or core_initcall.
>  - The only other Tegra core_initcall is tegra-hsp, and link order keeps
>    CBB ahead of it (drivers/soc/ links before drivers/mailbox/).
> 
> Acked-by: Sumit Gupta <sumitg@nvidia.com>

Thanks, Sumit and Jon!