[PATCH v4 0/4] Properly handle module_kobject creation

[PATCH v4 0/4] Properly handle module_kobject creation

[Shyam Saini]

Hi Everyone,

This patch series fixes handling of module_kobject creation.
A driver expect module_kset list populated with its corresponding
module_kobject to create its /sys/module/<built-in-module>/drivers
directory.

Since,
[1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
Call to populate module_kset list is deferred to save init time so that
external watchdog doesn't fireup on some boards and Linux can take
responsibility of feeding watchdog before it spuriously resets the
system. However, [1] this fix caused another issue i.e, consumers
of module_kset can't get related module_kobject during driver
initialisation and hence can't create their
/sys/module/<built-in-module>/drivers directory.

Consequently, [1] breaks user-space applications for eg: DPDK, which
expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.

The second issue was reported and the [2] revert of [1] was
proposed. However, [2] the Revert doesn't address the original issue
reported in [1].

This patch series addresses both issues reported in [1] and [2].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
[2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/

Thanks,
Shyam

---
- Changes in v4;
  - Restore accidentally removed empty line in kernel_add_sysfs_param()
  - Prepare this patch series for stable tree inclusion

- Changes in v3:
  - Split refactoring and globalisation of lookup_or_create_module_kobject() into two patches
  - Fix commit message to better describe the change.
  - Use IS_ENABLED instead of #ifdef macro construct
  - Undo the moving of __modinit macro construct into module.h
  - drop __modinit from lookup_or_create_module_kobject() declaration
  - Link: https://lore.kernel.org/lkml/20250211214842.1806521-1-shyamsaini@linux.microsoft.com/

Changes in v2:
- Undo the moving of to_module* and lookup_or_create_module_kobject() into module.h
- Refactor and globalize lookup_or_create_module_kobject()
- move __modinit macro construct to module.h
- Fix commit message typos
- Link: https://lore.kernel.org/lkml/20250207054538.1110340-1-shyamsaini@linux.microsoft.com/


Changes in v1: 
- Rename locate_module_kobject() to lookup_or_create_module_kobject() to accurately
  describe its operations.
- Moves lookup_or_create_module_kobject() and to_module* macros to module.h, so
  that driver code can use these.
- Handle module_kobject creation and population of module_kset list to fix [1]
  and [2] issues.
- Link: https://lore.kernel.org/lkml/20250204052222.1611510-1-shyamsaini@linux.microsoft.com/

Changes in RFC:
         Reverts commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")

Shyam Saini (4):
  kernel: param: rename locate_module_kobject
  kernel: refactor lookup_or_create_module_kobject()
  kernel: globalize lookup_or_create_module_kobject()
  drivers: base: handle module_kobject creation

 drivers/base/module.c  | 13 +++++-------
 include/linux/module.h |  2 ++
 kernel/params.c        | 47 ++++++++++++++++++++----------------------
 3 files changed, 29 insertions(+), 33 deletions(-)

-- 
2.34.1

[PATCH v4 1/4] kernel: param: rename locate_module_kobject

[Shyam Saini]

The locate_module_kobject() function looks up an existing
module_kobject for a given module name. If it cannot find the
corresponding module_kobject, it creates one for the given name.

This commit renames locate_module_kobject() to
lookup_or_create_module_kobject() to better describe its operations.

This doesn't change anything functionality wise.

Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
Cc: stable@kernel.org
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
---
 kernel/params.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index 2509f216c9f3..a2441ce059ae 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -760,7 +760,7 @@ void destroy_params(const struct kernel_param *params, unsigned num)
 			params[i].ops->free(params[i].arg);
 }
 
-static struct module_kobject * __init locate_module_kobject(const char *name)
+static struct module_kobject * __init lookup_or_create_module_kobject(const char *name)
 {
 	struct module_kobject *mk;
 	struct kobject *kobj;
@@ -802,7 +802,7 @@ static void __init kernel_add_sysfs_param(const char *name,
 	struct module_kobject *mk;
 	int err;
 
-	mk = locate_module_kobject(name);
+	mk = lookup_or_create_module_kobject(name);
 	if (!mk)
 		return;
 
@@ -873,7 +873,7 @@ static void __init version_sysfs_builtin(void)
 	int err;
 
 	for (vattr = __start___modver; vattr < __stop___modver; vattr++) {
-		mk = locate_module_kobject(vattr->module_name);
+		mk = lookup_or_create_module_kobject(vattr->module_name);
 		if (mk) {
 			err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
 			WARN_ON_ONCE(err);
-- 
2.34.1

[PATCH v4 2/4] kernel: refactor lookup_or_create_module_kobject()

[Shyam Saini]

In the unlikely event of the allocation failing, it is better to let
the machine boot with a not fully populated sysfs than to kill it with
this BUG_ON(). All callers are already prepared for
lookup_or_create_module_kobject() returning NULL.

This is also preparation for calling this function from non __init
code, where using BUG_ON for allocation failure handling is not
acceptable.

Since we are here, also start using IS_ENABLED instead of #ifdef
construct.

Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
Cc: stable@kernel.org
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
---
 kernel/params.c | 41 +++++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index a2441ce059ae..787662663e34 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -767,31 +767,28 @@ static struct module_kobject * __init lookup_or_create_module_kobject(const char
 	int err;
 
 	kobj = kset_find_obj(module_kset, name);
-	if (kobj) {
-		mk = to_module_kobject(kobj);
-	} else {
-		mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
-		BUG_ON(!mk);
-
-		mk->mod = THIS_MODULE;
-		mk->kobj.kset = module_kset;
-		err = kobject_init_and_add(&mk->kobj, &module_ktype, NULL,
-					   "%s", name);
-#ifdef CONFIG_MODULES
-		if (!err)
-			err = sysfs_create_file(&mk->kobj, &module_uevent.attr);
-#endif
-		if (err) {
-			kobject_put(&mk->kobj);
-			pr_crit("Adding module '%s' to sysfs failed (%d), the system may be unstable.\n",
-				name, err);
-			return NULL;
-		}
+	if (kobj)
+		return to_module_kobject(kobj);
 
-		/* So that we hold reference in both cases. */
-		kobject_get(&mk->kobj);
+	mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
+	if (!mk)
+		return NULL;
+
+	mk->mod = THIS_MODULE;
+	mk->kobj.kset = module_kset;
+	err = kobject_init_and_add(&mk->kobj, &module_ktype, NULL, "%s", name);
+	if (IS_ENABLED(CONFIG_MODULES) && !err)
+		err = sysfs_create_file(&mk->kobj, &module_uevent.attr);
+	if (err) {
+		kobject_put(&mk->kobj);
+		pr_crit("Adding module '%s' to sysfs failed (%d), the system may be unstable.\n",
+			name, err);
+		return NULL;
 	}
 
+	/* So that we hold reference in both cases. */
+	kobject_get(&mk->kobj);
+
 	return mk;
 }
 
-- 
2.34.1

[PATCH v4 3/4] kernel: globalize lookup_or_create_module_kobject()

[Shyam Saini]

lookup_or_create_module_kobject() is marked as static and __init,
to make it global drop static keyword.
Since this function can be called from non-init code, use __modinit
instead of __init, __modinit marker will make it __init if
CONFIG_MODULES is not defined.

Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
Cc: stable@kernel.org
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
---
 include/linux/module.h | 2 ++
 kernel/params.c        | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index d9a5183a9fe7..57044f2838be 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -162,6 +162,8 @@ extern void cleanup_module(void);
 #define __INITRODATA_OR_MODULE __INITRODATA
 #endif /*CONFIG_MODULES*/
 
+struct module_kobject *lookup_or_create_module_kobject(const char *name);
+
 /* Generic info of form tag = "info" */
 #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
 
diff --git a/kernel/params.c b/kernel/params.c
index 787662663e34..e668fc90b83e 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -760,7 +760,7 @@ void destroy_params(const struct kernel_param *params, unsigned num)
 			params[i].ops->free(params[i].arg);
 }
 
-static struct module_kobject * __init lookup_or_create_module_kobject(const char *name)
+struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
 {
 	struct module_kobject *mk;
 	struct kobject *kobj;
-- 
2.34.1

[PATCH v4 4/4] drivers: base: handle module_kobject creation

[Shyam Saini]

module_add_driver() relies on module_kset list for
/sys/module/<built-in-module>/drivers directory creation.

Since,
commit 96a1a2412acba ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
drivers which are initialized from subsys_initcall() or any other
higher precedence initcall couldn't find the related kobject entry
in the module_kset list because module_kset is not fully populated
by the time module_add_driver() refers it. As a consequence,
module_add_driver() returns early without calling make_driver_name().
Therefore, /sys/module/<built-in-module>/drivers is never created.

Fix this issue by letting module_add_driver() handle module_kobject
creation itself.

Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
Cc: stable@kernel.org
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
---
 drivers/base/module.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/base/module.c b/drivers/base/module.c
index 5bc71bea883a..218aaa096455 100644
--- a/drivers/base/module.c
+++ b/drivers/base/module.c
@@ -42,16 +42,13 @@ int module_add_driver(struct module *mod, const struct device_driver *drv)
 	if (mod)
 		mk = &mod->mkobj;
 	else if (drv->mod_name) {
-		struct kobject *mkobj;
-
-		/* Lookup built-in module entry in /sys/modules */
-		mkobj = kset_find_obj(module_kset, drv->mod_name);
-		if (mkobj) {
-			mk = container_of(mkobj, struct module_kobject, kobj);
+		/* Lookup or create built-in module entry in /sys/modules */
+		mk = lookup_or_create_module_kobject(drv->mod_name);
+		if (mk) {
 			/* remember our module structure */
 			drv->p->mkobj = mk;
-			/* kset_find_obj took a reference */
-			kobject_put(mkobj);
+			/* lookup_or_create_module_kobject took a reference */
+			kobject_put(&mk->kobj);
 		}
 	}
 
-- 
2.34.1

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Petr Pavlu]

On 2/27/25 19:49, Shyam Saini wrote:
> Hi Everyone,
> 
> This patch series fixes handling of module_kobject creation.
> A driver expect module_kset list populated with its corresponding
> module_kobject to create its /sys/module/<built-in-module>/drivers
> directory.
> 
> Since,
> [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> Call to populate module_kset list is deferred to save init time so that
> external watchdog doesn't fireup on some boards and Linux can take
> responsibility of feeding watchdog before it spuriously resets the
> system. However, [1] this fix caused another issue i.e, consumers
> of module_kset can't get related module_kobject during driver
> initialisation and hence can't create their
> /sys/module/<built-in-module>/drivers directory.
> 
> Consequently, [1] breaks user-space applications for eg: DPDK, which
> expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> 
> The second issue was reported and the [2] revert of [1] was
> proposed. However, [2] the Revert doesn't address the original issue
> reported in [1].
> 
> This patch series addresses both issues reported in [1] and [2].
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/

This looks ok to me. I only think the Fixes: tag should have remained
solely on the last patch in the series as that is the actual fix. I'll
adjust it when picking up the patches.

I'm going to wait for a few days if others still would like to comment
and then plan to queue this on modules-next.

@Greg, could I please get an Acked-by from you on the last patch in the
series as this affects the code in the driver core?

-- 
Thanks,
Petr

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Shyam Saini]

Hi Petr,

On Wed, Mar 05, 2025 at 10:55:03AM +0100, Petr Pavlu wrote:
> On 2/27/25 19:49, Shyam Saini wrote:
> > Hi Everyone,
> > 
> > This patch series fixes handling of module_kobject creation.
> > A driver expect module_kset list populated with its corresponding
> > module_kobject to create its /sys/module/<built-in-module>/drivers
> > directory.
> > 
> > Since,
> > [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> > Call to populate module_kset list is deferred to save init time so that
> > external watchdog doesn't fireup on some boards and Linux can take
> > responsibility of feeding watchdog before it spuriously resets the
> > system. However, [1] this fix caused another issue i.e, consumers
> > of module_kset can't get related module_kobject during driver
> > initialisation and hence can't create their
> > /sys/module/<built-in-module>/drivers directory.
> > 
> > Consequently, [1] breaks user-space applications for eg: DPDK, which
> > expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> > 
> > The second issue was reported and the [2] revert of [1] was
> > proposed. However, [2] the Revert doesn't address the original issue
> > reported in [1].
> > 
> > This patch series addresses both issues reported in [1] and [2].
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> > [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/
> 
> This looks ok to me. I only think the Fixes: tag should have remained
> solely on the last patch in the series as that is the actual fix. I'll
> adjust it when picking up the patches.
> 

Thank you for pointing that out, will take care of it next time.

I makred rest of the dependent patches for stable inclusion as per this [1] doc and, 
there was a warning from checkpatch scripts without Fixes: tag
WARNING: The commit message has 'stable@', `perhaps it also needs a 'Fixes:' tag?

Thanks,
Shyam

[1] https://docs.kernel.org/process/stable-kernel-rules.html#option-1

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Shyam Saini]

Hi Greg,

> On 2/27/25 19:49, Shyam Saini wrote:
> > Hi Everyone,
> > 
> > This patch series fixes handling of module_kobject creation.
> > A driver expect module_kset list populated with its corresponding
> > module_kobject to create its /sys/module/<built-in-module>/drivers
> > directory.
> > 
> > Since,
> > [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> > Call to populate module_kset list is deferred to save init time so that
> > external watchdog doesn't fireup on some boards and Linux can take
> > responsibility of feeding watchdog before it spuriously resets the
> > system. However, [1] this fix caused another issue i.e, consumers
> > of module_kset can't get related module_kobject during driver
> > initialisation and hence can't create their
> > /sys/module/<built-in-module>/drivers directory.
> > 
> > Consequently, [1] breaks user-space applications for eg: DPDK, which
> > expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> > 
> > The second issue was reported and the [2] revert of [1] was
> > proposed. However, [2] the Revert doesn't address the original issue
> > reported in [1].
> > 
> > This patch series addresses both issues reported in [1] and [2].
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> > [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/
> 
> This looks ok to me. I only think the Fixes: tag should have remained
> solely on the last patch in the series as that is the actual fix. I'll
> adjust it when picking up the patches.
> 
> I'm going to wait for a few days if others still would like to comment
> and then plan to queue this on modules-next.
> 
> @Greg, could I please get an Acked-by from you on the last patch in the
> series as this affects the code in the driver core?
>

do you have any feedback on last patch of this series?

Thanks,
Shyam

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Shyam Saini]

Hi Greg,

> On 2/27/25 19:49, Shyam Saini wrote:
> > Hi Everyone,
> > 
> > This patch series fixes handling of module_kobject creation.
> > A driver expect module_kset list populated with its corresponding
> > module_kobject to create its /sys/module/<built-in-module>/drivers
> > directory.
> > 
> > Since,
> > [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> > Call to populate module_kset list is deferred to save init time so that
> > external watchdog doesn't fireup on some boards and Linux can take
> > responsibility of feeding watchdog before it spuriously resets the
> > system. However, [1] this fix caused another issue i.e, consumers
> > of module_kset can't get related module_kobject during driver
> > initialisation and hence can't create their
> > /sys/module/<built-in-module>/drivers directory.
> > 
> > Consequently, [1] breaks user-space applications for eg: DPDK, which
> > expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> > 
> > The second issue was reported and the [2] revert of [1] was
> > proposed. However, [2] the Revert doesn't address the original issue
> > reported in [1].
> > 
> > This patch series addresses both issues reported in [1] and [2].
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> > [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/
> 
> This looks ok to me. I only think the Fixes: tag should have remained
> solely on the last patch in the series as that is the actual fix. I'll
> adjust it when picking up the patches.
> 
> I'm going to wait for a few days if others still would like to comment
> and then plan to queue this on modules-next.
> 
> @Greg, could I please get an Acked-by from you on the last patch in the
> series as this affects the code in the driver core?
> 

sorry for the frequent pings, could you please Ack last patch of this series
or perhaps provide any feedback ?

Thanks,
Shyam

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Greg KH]

On Tue, Apr 08, 2025 at 12:19:22PM -0700, Shyam Saini wrote:
> Hi Greg,
> 
> > On 2/27/25 19:49, Shyam Saini wrote:
> > > Hi Everyone,
> > > 
> > > This patch series fixes handling of module_kobject creation.
> > > A driver expect module_kset list populated with its corresponding
> > > module_kobject to create its /sys/module/<built-in-module>/drivers
> > > directory.
> > > 
> > > Since,
> > > [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> > > Call to populate module_kset list is deferred to save init time so that
> > > external watchdog doesn't fireup on some boards and Linux can take
> > > responsibility of feeding watchdog before it spuriously resets the
> > > system. However, [1] this fix caused another issue i.e, consumers
> > > of module_kset can't get related module_kobject during driver
> > > initialisation and hence can't create their
> > > /sys/module/<built-in-module>/drivers directory.
> > > 
> > > Consequently, [1] breaks user-space applications for eg: DPDK, which
> > > expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> > > 
> > > The second issue was reported and the [2] revert of [1] was
> > > proposed. However, [2] the Revert doesn't address the original issue
> > > reported in [1].
> > > 
> > > This patch series addresses both issues reported in [1] and [2].
> > > 
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> > > [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/
> > 
> > This looks ok to me. I only think the Fixes: tag should have remained
> > solely on the last patch in the series as that is the actual fix. I'll
> > adjust it when picking up the patches.
> > 
> > I'm going to wait for a few days if others still would like to comment
> > and then plan to queue this on modules-next.
> > 
> > @Greg, could I please get an Acked-by from you on the last patch in the
> > series as this affects the code in the driver core?
> > 
> 
> sorry for the frequent pings, could you please Ack last patch of this series
> or perhaps provide any feedback ?

The merge window _just_ ended, please give us a chance to catch up...

Re: [PATCH v4 4/4] drivers: base: handle module_kobject creation

[Greg KH]

On Thu, Feb 27, 2025 at 10:49:30AM -0800, Shyam Saini wrote:
> module_add_driver() relies on module_kset list for
> /sys/module/<built-in-module>/drivers directory creation.
> 
> Since,
> commit 96a1a2412acba ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> drivers which are initialized from subsys_initcall() or any other
> higher precedence initcall couldn't find the related kobject entry
> in the module_kset list because module_kset is not fully populated
> by the time module_add_driver() refers it. As a consequence,
> module_add_driver() returns early without calling make_driver_name().
> Therefore, /sys/module/<built-in-module>/drivers is never created.
> 
> Fix this issue by letting module_add_driver() handle module_kobject
> creation itself.
> 
> Fixes: 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> Cc: stable@kernel.org
> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> ---
>  drivers/base/module.c | 13 +++++--------
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/base/module.c b/drivers/base/module.c
> index 5bc71bea883a..218aaa096455 100644
> --- a/drivers/base/module.c
> +++ b/drivers/base/module.c
> @@ -42,16 +42,13 @@ int module_add_driver(struct module *mod, const struct device_driver *drv)
>  	if (mod)
>  		mk = &mod->mkobj;
>  	else if (drv->mod_name) {
> -		struct kobject *mkobj;
> -
> -		/* Lookup built-in module entry in /sys/modules */
> -		mkobj = kset_find_obj(module_kset, drv->mod_name);
> -		if (mkobj) {
> -			mk = container_of(mkobj, struct module_kobject, kobj);
> +		/* Lookup or create built-in module entry in /sys/modules */
> +		mk = lookup_or_create_module_kobject(drv->mod_name);
> +		if (mk) {
>  			/* remember our module structure */
>  			drv->p->mkobj = mk;
> -			/* kset_find_obj took a reference */
> -			kobject_put(mkobj);
> +			/* lookup_or_create_module_kobject took a reference */
> +			kobject_put(&mk->kobj);
>  		}
>  	}
>  
> -- 
> 2.34.1

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH v4 0/4] Properly handle module_kobject creation

[Petr Pavlu]

On 2/27/25 19:49, Shyam Saini wrote:
> Hi Everyone,
> 
> This patch series fixes handling of module_kobject creation.
> A driver expect module_kset list populated with its corresponding
> module_kobject to create its /sys/module/<built-in-module>/drivers
> directory.
> 
> Since,
> [1] commit 96a1a2412acb ("kernel/params.c: defer most of param_sysfs_init() to late_initcall time")
> Call to populate module_kset list is deferred to save init time so that
> external watchdog doesn't fireup on some boards and Linux can take
> responsibility of feeding watchdog before it spuriously resets the
> system. However, [1] this fix caused another issue i.e, consumers
> of module_kset can't get related module_kobject during driver
> initialisation and hence can't create their
> /sys/module/<built-in-module>/drivers directory.
> 
> Consequently, [1] breaks user-space applications for eg: DPDK, which
> expects /sys/module/vfio_pci/drivers/pci:vfio-pci/new_id to be present.
> 
> The second issue was reported and the [2] revert of [1] was
> proposed. However, [2] the Revert doesn't address the original issue
> reported in [1].
> 
> This patch series addresses both issues reported in [1] and [2].
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96a1a2412acb
> [2] https://lore.kernel.org/lkml/20250130225803.321004-1-shyamsaini@linux.microsoft.com/

I've queued now the series on modules-fixes, with some minor cleanups to
the commit messages.

I changed the "Cc: stable@kernel.org" tag on the last patch to "Cc:
stable@vger.kernel.org". Documentation/process/stable-kernel-rules.rst
recommends using the latter address by default, unless the patch is
fixing unpublished vulnerabilities.

I've removed "Fixes: 96a1a2412acb" and "Cc: stable@kernel.org" from the
first three patches because only the final patch contains the actual
fix. I suspect the stable tooling should automatically determine the
dependencies in this case, but to be explicit, I added a note to
stable@vger.kernel.org on the last patch indicating that it requires all
other patches from the series.

-- 
Thanks,
Petr