From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Shyam Saini <shyamsaini@linux.microsoft.com>
Cc: linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
code@tyhicks.com, christophe.leroy@csgroup.eu,
hch@infradead.org, mcgrof@kernel.org,
frkaya@linux.microsoft.com, vijayb@linux.microsoft.com,
petr.pavlu@suse.com, linux@weissschuh.net,
samitolvanen@google.com, da.gomez@samsung.com,
gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org
Subject: Re: [v2 2/3] kernel: refactor and globalize lookup_or_create_module_kobject()
Date: Fri, 07 Feb 2025 10:23:37 +0100 [thread overview]
Message-ID: <87ikpmrtuu.fsf@prevas.dk> (raw)
In-Reply-To: <20250207054538.1110340-3-shyamsaini@linux.microsoft.com> (Shyam Saini's message of "Thu, 6 Feb 2025 21:45:37 -0800")
On Thu, Feb 06 2025, Shyam Saini <shyamsaini@linux.microsoft.com> wrote:
> lookup_or_create_module_kobject() is static and marked as __init,
> this is not ideal for global usage.
>
> Fix this limitation by refactoring and declaring this as global:
> - Refactor it by removing BUG_ON() and 'if else' construct by returning
> early
> - Remove static and __init markers from the function and add its
> declaration in module.h
> - Mark this function as "__modinit". To facilitate this, move the
> __modinit macro construct to module.h
>
I think this does too much in one patch.
More or less any time you find yourself writing such a bullet list, ask
yourself it that doesn't mean you're really writing three distinct
commit messages (and thus should make it three patches).
This also forces you to explicitly justify the removal of BUG_ON(),
instead of merely stating that the patch does that (the "what" is clear
from the patch itself, the commit message is for the "why"). Something like
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.
That will also make it much easier to verify that the refactoring commit
does only that and doesn't accidentally introduce some subtle change.
Actually, since you're not moving the function anymore (and shouldn't),
you don't really _need_ to include that refactoring patch, but it would be
a nice thing to have since you're touching this code anyway.
> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> ---
> include/linux/module.h | 8 +++++++
> kernel/params.c | 48 ++++++++++++++++++------------------------
> 2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 12f8a7d4fc1c..57d09b4e4385 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -162,6 +162,14 @@ extern void cleanup_module(void);
> #define __INITRODATA_OR_MODULE __INITRODATA
> #endif /*CONFIG_MODULES*/
>
> +#ifdef CONFIG_MODULES
> +#define __modinit
> +#else
> +#define __modinit __init
> +#endif
> +
> +struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name);
> +
No, the section placement doesn't need to, and should not, be on the
declaration, that just belongs with the definition. So there's no reason
to move that __modinit definition and make it globally visible.
Rasmus
next prev parent reply other threads:[~2025-02-07 9:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 5:45 [v2 0/3] Properly handle module_kobject creation Shyam Saini
2025-02-07 5:45 ` [v2 1/3] kernel: param: rename locate_module_kobject Shyam Saini
2025-02-07 5:45 ` [v2 2/3] kernel: refactor and globalize lookup_or_create_module_kobject() Shyam Saini
2025-02-07 7:35 ` Thomas Weißschuh
2025-02-07 9:23 ` Rasmus Villemoes [this message]
2025-02-07 5:45 ` [v2 3/3] drivers: base: handle module_kobject creation Shyam Saini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ikpmrtuu.fsf@prevas.dk \
--to=linux@rasmusvillemoes.dk \
--cc=christophe.leroy@csgroup.eu \
--cc=code@tyhicks.com \
--cc=da.gomez@samsung.com \
--cc=dakr@kernel.org \
--cc=frkaya@linux.microsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=rafael@kernel.org \
--cc=samitolvanen@google.com \
--cc=shyamsaini@linux.microsoft.com \
--cc=vijayb@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox