public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox