+++ Luis R. Rodriguez [08/12/16 11:49 -0800]:
kmod has an optimization in place whereby if a some kernel code uses request_module() on a module already loaded we never bother userspace as the module already is loaded. This is not true for get_fs_type() though as it uses aliases. Additionally kmod <= v19 was broken -- it returns 0 to modprobe calls, assuming the kernel module is built-in, where really we have a race as the module starts forming. kmod <= v19 has incorrect userspace heuristics, a userspace kmod fix is available for it: http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkmod-module.c?id=fd44a98ae2eb5eb32161088954ab21e58e19dfc4 This changes kmod to address both: o Provides the alias optimization for get_fs_type() so modules already loaded do not get re-requested. o Provides a sanity test to verify modprobe's work This is important given how any get_fs_type() users assert success means we're ready to go, and tests with the new test_kmod stress driver reveal that request_module() and get_fs_type() might fail for a few other reasons. You don't need old kmod to fail on request_module() or get_fs_type(), with the right system setup, these calls *can* fail today. Although this does get us in the business of keeping alias maps in kernel, the the work to support and maintain this is trivial. Aditionally, since it may be important get_fs_type() should not fail on certain systems, this tightens things up a bit more. The TL;DR: kmod <= v19 will return 0 on modprobe calls if you are built-in, however its heuristics for checking if you are built-in were broken. It assumed that having the directory /sys/module/module-name but not having the file /sys/module/module-name/initstate is sufficient to assume a module is built-in. The kernel loads the inittstate attribute *after* it creates the directory. This is an issue when modprobe returns 0 for kernel calls which assumes a return of 0 on request_module() can give you the right to assert the module is loaded and live. We cannot trust returns of modprobe as 0 in the kernel, we need to verify that modules are live if modprobe return 0 but only if modules *are* modules. The kernel heuristic we use to determine if a module is built-in is that if modprobe returns 0 we know we must be built-in or a module, but if we are a module clearly we must have a lingering kmod dangling on our linked list. If there is no modules there we are *somewhat* certain the module must be built in. This is not enough though... we cannot easily work around this since the kernel can use aliases to userspace for modules calls. For instance fs/namespace.c uses fs-modulename for filesystesms on get_fs_type(), so these need to be taken into consideration as well. Using kmod <= 19 will give you a NULL get_fs_type() return even though the module was loaded... That is a corner case, there are other failures for request_module() though -- the other failures are not easy to reproduce though but fortunately we have a stress test driver to help with that now. Use the following tests: # tools/testing/selftests/kmod/kmod.sh -t 0008 # tools/testing/selftests/kmod/kmod.sh -t 0009 You can more easily see this error if you have kmod <= v19 installed. You will need to install kmod <= v19, be sure to install its modprobe into /sbin/ as by default the 'make install' target does not replace your own. This test helps cure test_kmod cases 0008 0009 so enable them. Reported-by: Martin Wilck <martin.wilck@xxxxxxxx> Reported-by: Randy Wright <rwright@xxxxxxx> Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxx>
Back from travel today, apologies for the delay. Will be able to give this a proper look this week. Jessica -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
