From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Petr Pavlu <petr.pavlu@suse.com>
Cc: Shyam Saini <shyamsaini@linux.microsoft.com>,
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,
linux@weissschuh.net, samitolvanen@google.com,
da.gomez@samsung.com, gregkh@linuxfoundation.org,
rafael@kernel.org, dakr@kernel.org
Subject: Re: [PATCH v3 2/4] kernel: refactor lookup_or_create_module_kobject()
Date: Fri, 21 Feb 2025 11:42:22 +0100 [thread overview]
Message-ID: <87wmdjo9yp.fsf@prevas.dk> (raw)
In-Reply-To: <4039ec74-8b46-417e-ad71-eff22239b90f@suse.com> (Petr Pavlu's message of "Thu, 13 Feb 2025 16:55:54 +0100")
On Thu, Feb 13 2025, Petr Pavlu <petr.pavlu@suse.com> wrote:
> On 2/11/25 22:48, Shyam Saini wrote:
>> 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.
>
> I think some error reporting should be cleaned up here.
>
> The current situation is that locate_module_kobject() can fail in
> several cases and all these situations are loudly reported by the
> function, either by BUG_ON() or pr_crit(). Consistently with that, both
> its current callers version_sysfs_builtin() and kernel_add_sysfs_param()
> don't do any reporting if locate_module_kobject() fails; they simply
> return.
>
> The series seems to introduce two somewhat suboptimal cases.
>
> With this patch, when either version_sysfs_builtin() or
> kernel_add_sysfs_param() calls lookup_or_create_module_kobject() and it
> fails because of a potential kzalloc() error, the problem is silently
> ignored.
>
No, because (IIUC) when a basic allocation via kzalloc fails, the kernel
complains loudly already; there's no reason for every caller of
kmalloc() and friends to add their own pr_err("kmalloc failed"), that
just bloats the kernel .text.
> Similarly, in the patch #4, when module_add_driver() calls
> lookup_or_create_module_kobject() and the function fails, the problem
> may or may not be reported, depending on the error.
>
> I'd suggest something as follows:
> * Drop the pr_crit() reporting in lookup_or_create_module_kobject().
No, because that reports on something other than an allocation failing
(of course, it could be that the reason kobject_init_and_add or
sysfs_create_file failed was an allocation failure, but it could
also be something else), so reporting there is the right thing to do.
> * Have version_sysfs_builtin() and kernel_add_sysfs_param() log an error
> when lookup_or_create_module_kobject() fails. Using BUG_ON() might be
> appropriate, as that is already what is used in
> kernel_add_sysfs_param()?
No, BUG_ON is almost never appropriate, and certainly not for something
which the machine can easily survice, albeit perhaps with some
functionality not available. That this had a BUG_ON is simply a
historical artefact, nothing more, and borderline acceptable as lazy
error handling in __init code, as small allocations during system init
simply don't fail (and if they did, the system would be unusable
anyway).
Rasmus
next prev parent reply other threads:[~2025-02-21 10:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 21:48 [PATCH v3 0/4] Properly handle module_kobject creation Shyam Saini
2025-02-11 21:48 ` [PATCH v3 1/4] kernel: param: rename locate_module_kobject Shyam Saini
2025-02-13 15:57 ` Petr Pavlu
2025-02-11 21:48 ` [PATCH v3 2/4] kernel: refactor lookup_or_create_module_kobject() Shyam Saini
2025-02-13 15:55 ` Petr Pavlu
2025-02-21 10:42 ` Rasmus Villemoes [this message]
2025-02-25 8:33 ` Petr Pavlu
2025-02-25 17:24 ` Shyam Saini
2025-02-27 13:08 ` Petr Pavlu
2025-02-11 21:48 ` [PATCH v3 3/4] kernel: globalize lookup_or_create_module_kobject() Shyam Saini
2025-02-13 15:59 ` Petr Pavlu
2025-02-21 10:48 ` Rasmus Villemoes
2025-02-11 21:48 ` [PATCH v3 4/4] drivers: base: handle module_kobject creation Shyam Saini
2025-02-20 12:01 ` Greg KH
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=87wmdjo9yp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.