From: "Arnd Bergmann" <arnd@arndb.de>
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: "Luis Chamberlain" <mcgrof@kernel.org>,
"Petr Pavlu" <petr.pavlu@suse.com>,
da.gomez@kernel.org, "Sami Tolvanen" <samitolvanen@google.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
neelx@suse.com, da.anzani@gmail.com, sean@ashe.io,
chjohnst@mail.com, steve@abita.co, mproche@mail.com,
nick.lane@mail.com, Linux-Arch <linux-arch@vger.kernel.org>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] module: Extend module_blacklist parameter to built-in modules
Date: Mon, 13 Jul 2026 10:32:14 +0200 [thread overview]
Message-ID: <78ec1da5-11ae-4c35-a08e-cc88a5d083f4@app.fastmail.com> (raw)
In-Reply-To: <in7aczdvb22suqhao6uzsjkh22tgyx2qug4i6efdxyfiuj72ba@k6fr4oc27kim>
On Sat, Jul 11, 2026, at 01:13, Aaron Tomlin wrote:
> On Fri, Jul 10, 2026 at 05:59:59PM +0200, Arnd Bergmann wrote:
>> On Wed, Jul 8, 2026, at 04:00, Aaron Tomlin wrote:
>> > Currently, the "module_blacklist=" command-line parameter only applies
>> > to loadable modules. If a module is built-in, the parameter is silently
>> > ignored. This patch extends the blacklisting functionality to built-in
>> > modules by intercepting their initialisation routines during early boot.
>>
>> Andrew already asked you to provide more background on what you need
>> this part for. Do you have a specific driver you need to disable?
>>
>> Can't you do the same thing using initcall_blacklist?
>
> The primary motivation for this patch is to provide consistent
> administrative control.
Ok, it sounds like you don't actually need it then.
> Regarding your suggestion to use initcall_blacklist=, while it is certainly
> a capable mechanism, it is fundamentally considered a debugging facility
> intended for developers.
I don't see much of a difference here, it's clearly still only a
debugging tool to me, not a general administrative interface: turning
off a random built-in driver likely causes undefined behavior later
if there are any other drivers (built-in or loaded) that depend on it.
Overall I don't think it's worth the added complexity.
Arnd
next prev parent reply other threads:[~2026-07-13 8:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 2:00 [PATCH v4] module: Extend module_blacklist parameter to built-in modules Aaron Tomlin
2026-07-10 15:42 ` Sami Tolvanen
2026-07-10 15:59 ` Arnd Bergmann
2026-07-10 23:13 ` Aaron Tomlin
2026-07-13 8:32 ` Arnd Bergmann [this message]
2026-07-13 12:13 ` Aaron Tomlin
2026-07-13 16:02 ` Petr Pavlu
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=78ec1da5-11ae-4c35-a08e-cc88a5d083f4@app.fastmail.com \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=atomlin@atomlin.com \
--cc=chjohnst@mail.com \
--cc=da.anzani@gmail.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=mhiramat@kernel.org \
--cc=mproche@mail.com \
--cc=neelx@suse.com \
--cc=nick.lane@mail.com \
--cc=peterz@infradead.org \
--cc=petr.pavlu@suse.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