Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: built-in vs loadable modules and userconf



On Sat, 19 Oct 2019, John D. Baker wrote:

On Sat, 19 Oct 2019, Paul Goyette wrote:

I want to be sure that a disabled built-in module won't cause a loadable
module to be loaded and defeat the disabling of the built-in "raid" device.

Disabling the raid device in userconf doesn't disable the raidframe module.
If the raidframe module is in your kernel, it can only be disabled after
booting, using modunload(8).

All raidframe support is built-in on my kernel (includes GENERIC and
elides unnecessary/unwanted items).  If I disable all the raid* stuff,
won't that disable raidframe as well?

From the module(9) perspective, no, the module is not disabled as a
result of userconf activity.

Using userconf to disable the device will prevent all accesses to the
device.  BUT, the module will still be active, and the module's
initialization code will be called.  Any code in the kernel that looks
for auto-configured raid devices will still run.  I would expect it to
fail to create any actual raid instances, but the code should still
execute.

It's important that everything raidframe/raid related be disabled before
the kernel boots, or my RAID will be hosed again and I don't need that
level of stress.  I was lucky to recover it the first time (have
encountered a few damaged files since then).

Given that you've had "issues" with raid's auto-configure before, I
would be reluctant to try this with your current kernel.  I would
suggest that you build a new kernel with no raid config(1)ured.

Also note that disabling a built-in module does not allow you to load a
different instance of that module.  modload(8) will find the built-in module,

I think that means if I disable something via userconf, the on-disk
loadable module won't be loaded.

If the module is built-in, it will never be loaded from the *.kmod file.
But as I pointed out above, disabling in userconf does NOT disable the
module, and does not prevent the module's initialization code from
executing.


I suppose I could whip up a custom kernel without the raidframe/raid
support in it, but it's crucial to keep the raidframe module from being
loaded if any disk is found with RAID autoconf support.

If you build a custom kernel without any raid support, then there will
be no code to look for any auto-configured-raid-sets, and therefore no
code to instantiate any raid devices, and therefore no reason to ever
attempt to autoload the module.

If you're really paranoid, you can also configure your custom kernel
with MODULAR_DEFAULT_AUTOLOAD disabled (this is on by default).

I suppose also I can turn off autoconfig on the RAID before booting the
test kernel (the config file is renamed so it won't be found by the
'rc' scripts).

I have another machine with a local raidframe raid that I can test the
procedure with when current tasks are completed.


Hope this helps!



+--------------------+--------------------------+-----------------------+
| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
+--------------------+--------------------------+-----------------------+


Home | Main Index | Thread Index | Old Index