blacklisting is not implemented by the kernel. It is implemented by
When a user manually requests to load a named module, it is not affected by the blacklist.
blacklisting exists to prevent modules being automatically loaded by 1) udev, when it detects hardware, 2) kernel calls of request_module() which load modules on-demand, if the request_module() call is for a module alias like
(udev's usage is also a case of loading modules using their aliases. E.g. the alias
scsi:t-0x01*, is used for a scsi device which requires the
st driver module).
Scripts which call
modprobe with a module name, and do not pass
-b to modprobe, are not affected by the blacklist. You may request that the script be amended accordingly - I guess this is the reason for having the
-b option - or disable the script in question using some other method :-).
There might also be a few uses of request_module() inside the kernel which request a module by name, not by an alias. request_module() does not pass
-b when it runs
The blacklist is also not consulted when
modprobe loads a kernel module as a requirement of another module. This should not be a big problem when you want to stop certain driver modules being loaded automatically... you might need to find out which is the module loaded by udev, or else make sure to blacklist a few different possibilities.
So you originally asked about the kernel design, but you may as well ask why the
modprobe command does not imply
-b by default.
Why even have an option to ignore [the blacklist]?
obviously "if you don't want a module to be loaded automatically, but you want to be able to load it manually when desired".
My default assumption is this was not a design goal, and it happens not to fulfil it. And once a design is widespread, some types of changes are risky or guarantee to break existing systems. I would also note that blacklists were not part of the first version of the module-loading command.
Also, notice that a config line like
install bad-module /bin/false avoids all of the above "weaknesses". Technically this is "not assured and it is intended to replace [the install command]", although by this point it has been around "for the long term" and survived at least one re-write/re-licensing (
module-init-tools project ->
kmod project), with no-one having implemented a replacement for it.
I found one example of a user who does wants to bypass a blacklist. However this does not seem a good example, as the thread shows a different solution which seems obviously the right thing to do IMO.
It can also be convenient when experimenting, to see whether you want to use a module which is currently blacklisted. Although the most obvious example that comes to mind is graphics drivers, where you would want to test a full reboot, so it would be best to just edit the blacklist file.
Weak points in the above answer -
It sounds like there is no logging to show you when request_module() calls happen. So there is not much transparency here, when you want to rule out request_module() calls as a possible factor.
Once you have a module loaded, it is easy to check in
lsmod if it is being used by another module. But this would not help e.g. if the module is so buggy that it crashes the system immediately when it is loaded :-). And I don't think there is a pre-made command, to search for which modules have a hard requirement on a specific module X.
modprobe --show-depends X shows the opposite direction.
Some other unknown complexities. Because it is really not clear to me that either of the above points explains the problem in the question Blacklisting modules in modprobe.d and kernel params is not working