From: Petr Pavlu <petr.pavlu@suse.com>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: arnd@arndb.de, mcgrof@kernel.org, da.gomez@kernel.org,
samitolvanen@google.com, neelx@suse.com, sean@ashe.io,
chjohnst@mail.com, steve@abita.co, mproche@mail.com,
nick.lane@mail.com, linux-arch@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] init/main: Expose built-in initcalls and blacklist status via debugfs
Date: Wed, 17 Jun 2026 14:39:53 +0200 [thread overview]
Message-ID: <79ace94f-31d3-4a5e-9a47-3fad69304fe5@suse.com> (raw)
In-Reply-To: <20260510061301.41341-1-atomlin@atomlin.com>
On 5/10/26 8:13 AM, Aaron Tomlin wrote:
> At present, identifying the correct function name to supply to the
> "initcall_blacklist=" kernel command-line parameter requires manual
> inspection of the source code or kernel symbol tables. Furthermore,
> administrators lack a reliable runtime mechanism to verify whether a
> specified built-in module has been successfully blacklisted.
My understanding is that initcall_blacklist is primarily a debugging
facility. This is documented in
Documentation/admin-guide/kernel-parameters.txt [1] and also outlined in
the initial commit 7b0b73d76651 ("init/main.c: add initcall_blacklist
kernel parameter") [2]. It is expected that to use it, one must inspect
the kernel source code.
If the goal is to allow specific built-in modules to be blacklisted,
I wonder whether extending module_blacklist to also cover built-in
modules might be a better option. Module names are more appropriate for
administrators to use, while initcall names should remain internal to
the kernel. Additionally, initcalls are typically "static" and therefore
are not guaranteed to have unique names + using module names avoids
a dependency on CONFIG_KALLSYMS=y.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v7.1#n2408
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b0b73d76651e5f88c88b76efa18d719f832bf6f
--
Thanks,
Petr
next prev parent reply other threads:[~2026-06-17 12:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 6:13 [PATCH] init/main: Expose built-in initcalls and blacklist status via debugfs Aaron Tomlin
2026-05-11 20:34 ` Aaron Tomlin
2026-06-13 21:05 ` Aaron Tomlin
2026-06-17 12:39 ` Petr Pavlu [this message]
2026-06-20 23:11 ` Aaron Tomlin
2026-06-25 23:50 ` Andrew Morton
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=79ace94f-31d3-4a5e-9a47-3fad69304fe5@suse.com \
--to=petr.pavlu@suse.com \
--cc=arnd@arndb.de \
--cc=atomlin@atomlin.com \
--cc=chjohnst@mail.com \
--cc=da.gomez@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mproche@mail.com \
--cc=neelx@suse.com \
--cc=nick.lane@mail.com \
--cc=samitolvanen@google.com \
--cc=sean@ashe.io \
--cc=steve@abita.co \
/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