[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae1f74bd-4e8c-4031-8175-240f5f8d7f17@suse.com>
Date: Wed, 5 Mar 2025 10:55:03 +0100
From: Petr Pavlu <petr.pavlu@...e.com>
To: Shyam Saini <shyamsaini@...ux.microsoft.com>, gregkh@...uxfoundation.org
Cc: linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
code@...icks.com, linux@...musvillemoes.dk, christophe.leroy@...roup.eu,
hch@...radead.org, mcgrof@...nel.org, frkaya@...ux.microsoft.com,
vijayb@...ux.microsoft.com, linux@...ssschuh.net, samitolvanen@...gle.com,
da.gomez@...sung.com, rafael@...nel.org, dakr@...nel.org
Subject: Re: [PATCH v4 0/4] Properly handle module_kobject creation
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
Powered by blists - more mailing lists