linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Christoph Hellwig <hch@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>,
	linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] Add kernel parameter to blacklist modules
Date: Tue, 14 Jun 2016 17:51:34 -0300	[thread overview]
Message-ID: <20160614205134.GA16214@khazad-dum.debian.net> (raw)
In-Reply-To: <20160614171702.GA20693@infradead.org>

On Tue, 14 Jun 2016, Christoph Hellwig wrote:
> On Mon, Jun 13, 2016 at 08:32:41AM -0400, Prarit Bhargava wrote:
> > Blacklisting a module in linux has long been a problem.  The process of
> > blacklisting a module has changed over time, and it seems that every OS
> > does it slightly differently and depends on the age of the init system
> > used on that OS.
> 
> And why would we care about blacklisting a module?

Because the "Current Best Practice" way to help users blacklist modules
that won't drag you to nasty places trying to ensure they did it right
(i.e. "mv" the .ko file away then trigger an initramfs update and
reboot) just covers situations where the system actually boots/installs
mostly fine in the first place.

So, yes, such a feature looks like it would be rather useful, to the
point that I'd even advocate for it to be backported (once it has been
in a released mainline kernel for a while to remove any risk of
regressions, of course).

And if such a module blacklist feature ends up being invoked by the
"nuke_module_from_orbit=<modules list>" parameter, I will pay the author
(and the subsystem maintainer that manages to get that merged) a couple
beers should we ever meet in real life :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  parent reply	other threads:[~2016-06-14 20:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 12:32 [PATCH] Add kernel parameter to blacklist modules Prarit Bhargava
2016-06-13 21:23 ` Rusty Russell
2016-06-14 17:15   ` [PATCH v2] " Prarit Bhargava
2016-06-14 21:20     ` Rusty Russell
2016-06-15 13:38       ` Prarit Bhargava
2016-06-14 17:17 ` [PATCH] " Christoph Hellwig
2016-06-14 17:55   ` Prarit Bhargava
2016-06-14 20:51   ` Henrique de Moraes Holschuh [this message]
2016-06-14 22:51     ` Prarit Bhargava

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=20160614205134.GA16214@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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;
as well as URLs for NNTP newsgroup(s).