[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z6GlVpuR8MaR4XLN@infradead.org>
Date: Mon, 3 Feb 2025 21:27:50 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Shyam Saini <shyamsaini@...ux.microsoft.com>
Cc: linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
code@...icks.com, linux@...musvillemoes.dk, mcgrof@...nel.org,
frkaya@...ux.microsoft.com, vijayb@...ux.microsoft.com,
petr.pavlu@...e.com, linux@...ssschuh.net, samitolvanen@...gle.com,
da.gomez@...sung.com, gregkh@...uxfoundation.org, rafael@...nel.org,
dakr@...nel.org
Subject: Re: [v1 2/3] include: move
lookup_or_create_module_kobject()/to_module* to module.h
> +static inline struct module_kobject * __init lookup_or_create_module_kobject(const char *name)
Crazily unreadable line.
Either way this is not a function that should be inline in a header.
Both due to sheer size, but also due to what it does and what it pulls
in.
> +{
> + struct module_kobject *mk;
> + struct kobject *kobj;
> + int err;
> +
> + kobj = kset_find_obj(module_kset, name);
> + if (kobj) {
> + mk = to_module_kobject(kobj);
> + } else {
And I know this is just moving the code, but an ealy return here
would significanty clean up the function..
> + mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
> + BUG_ON(!mk);
.. and a BUG_ON on allocation failure is a no-go.
Powered by blists - more mailing lists