If loading a module that is already loading, and the module parameters for modprobe don't match the parameters set for the load. In the case of bug 659352, the initramfs loaded the bonding module, and then when /etc/init.d/modules loaded later, it tried to modprobe again, with specific params, and the effective result was that the param was not set. Proposal: 1. Before loading a module, check if it's already loaded. 2. If not loaded, load with params. 3. If loaded, check params. 4. If param matches, no error. 5. If param does NOT match new setting, print an error.
It looks like steps 1 and 2 above can be handled by the --first-time switch for modprobe. This switch causes modprobe to refuse to load the module if it is already loaded and exit with an error. Unfortunately, I do not see a standard way to see which parameters were used when a module was loaded, apparently because some modules don't store their parameters in /sys/module/<modname>/parameters/*. Would you be ok with us just complaining if a module is already loaded? I think the only other option would be to unload and reload the module, but I think that wouldn't be a good idea. What do you think? [1] https://serverfault.com/questions/62316/how-do-i-list-loaded-linux-module-parameter-values
(In reply to William Hubbs from comment #1) > Unfortunately, I do not see a standard way to see which parameters were > used when a module was loaded, apparently because some modules don't > store their parameters in /sys/module/<modname>/parameters/*. What modules did you find like that? That would take doing in the kernel, because modparams have been exposed by default in sysfs for a long time.
(In reply to Robin Johnson from comment #2) > (In reply to William Hubbs from comment #1) > > Unfortunately, I do not see a standard way to see which parameters were > > used when a module was loaded, apparently because some modules don't > > store their parameters in /sys/module/<modname>/parameters/*. > What modules did you find like that? That would take doing in the kernel, > because modparams have been exposed by default in sysfs for a long time. I haven't looked at any specific modules, I've just been researching ways to find out what the options are that modules are loaded with. This one seems to imply that modules can decide which parameters are exported to /sys/module/<modname>/parameters. [2] https://www.linuxquestions.org/questions/linux-general-1/show-options-that-kernel-module-was-loaded-with-624228/
(In reply to William Hubbs from comment #3) > I haven't looked at any specific modules, I've just been researching ways to > find out what the options are that modules are loaded with. > > This one seems to imply that modules can decide which parameters are > exported to /sys/module/<modname>/parameters. Ok, I went and checked the ~2500 modules I had built on my laptop. Loaded all of them, compared modinfo output to sysfs. I got ~2300 unique module parameters total. Of that: ~2100 are available at module load time. ~200 can only be set AFTER the module is loaded (this was a surprise to me, they show up in sysfs but NOT modinfo). Of the ~2100 that are available at module load time, ~1850 are exposed in sysfs. So here's my proposed code idea: When loading a module with parameters given: 1. If a matching file in /parameters/ exists, verify against it. 2. Throw warning if mismatch (also handles type conversion cases for bool N=>0, and int/hex). 3. If the file in /parameters/ does NOT exist, just throw a warning that we are unable to verify the parameters. The bonding module in the original bug turns out to be an example of a module that does not expose the set parameters to sysfs.
Here is a related question I posed on IRC. Kernel modules can be loaded from any or all of these three places. 1. an initramfs 2. settings in the modules-load.d directories 3. settings in conf.d Is it reasonable for options 2 and 3 to complain about loading modules that are already loaded, regardless of what the parameters passed to the modules are?
(In reply to William Hubbs from comment #5) > Is it reasonable for options 2 and 3 to complain about loading modules that > are already loaded, regardless of what the parameters passed to the modules > are? Yes, I think a non-fatal ewarn there is reasonable.
(In reply to William Hubbs from comment #5) > Here is a related question I posed on IRC. > > Kernel modules can be loaded from any or all of these three places. > > 1. an initramfs > 2. settings in the modules-load.d directories > 3. settings in conf.d > > Is it reasonable for options 2 and 3 to complain about loading modules that > are already loaded, regardless of what the parameters passed to the modules > are? Don't forget autoloading via udev, etc.
This commit, which will be part of 0.39, generates non-fatal errors if the boot sequence loads a module that is already loaded. https://github.com/openrc/openrc/commit/d70b1c55b67b44b98c23ceed25bc428481f7e00a
