yep, having up to 3 seconds worth of stale system data is too much time. Also, I think the builtins can just validate themselves - for example the kmod builtin can trivially call kmod_validate_resource(ctx) every time it's asked to load a module, and I think the other builtins that implement .validate probably also can self-validate too, and remove the udev_builtin_validate() call entirely.
I have a small draft patch just to the kmod builtin that I'm testing: https://code.launchpad.net/~ddstreet/+git/systemd/+ref/sf149300 I'll take another look next week to see if it can be expanded to cover all the builtins that do validation, and submit something upstream for discussion. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1714505 Title: systemd kmod builtin uses out of date kmod context Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Bug description: [Impact] udev's rules use a built-in 'kmod' instead of the system modprobe/insmod, and this built-in kmod only validates/refreshes its kmod 'context' every 3 seconds (or longer) during event processing. However, because other parts of the system rely on udev to load modules correctly, it is not acceptable for it to use an out of date module context. For example, during a system installation: -the system boots with kernel and initrd with a reduced set of modules, not including nvme module -udevd starts, and creates its kmod module context, which does not include nvme module -system installer adds 'block-modules' udeb, which adds nvme module to system -system installer immediately calls hw-detect->update-dev->udevadm trigger -udevd sees its kmod module context is not more than 3 seconds old, and does not update it -udevd rule 80-drivers.rules finds NVMe pci modalias and asks kmod builtin to load matching driver -udevd kmod builtin does not find NVMe pci modalias because its context is out of date this results in the system installer complaining to the user that it found no disks, even though there is a NVMe drive in the system, and the nvme module is installed in the system. [Test Case] This is reproducable when trying to install using debian-installer and a preseed file that skips all questions, although not on all systems, since other events can cause udevd to reload all its builtins, or the installer may take longer than 3 seconds to call udevadm trigger after installing the nvme module udeb. However, the bug is easily reproducable on any system with a nvme drive using this script: #!/bin/bash MOD_DIR=/lib/modules/$( uname -r )/kernel/drivers/nvme/host modprobe -rq nvme mv $MOD_DIR/nvme.ko . depmod -a sleep 3 udevadm trigger sleep 1 mv nvme.ko $MOD_DIR/ depmod -a udevadm trigger sleep 3 grep -q nvme /proc/partitions && echo PASS || echo FAIL that script does: 1) remove nvme module from the system, reproducing situation where nvme module had not yet been installed 2) waits 3 seconds, because the udev kmod validation timeout is 3 seconds 3) triggers udev, which forces it to reload its kmod context (this could be done with udevadm control -R instead) 4) waits 1 second for the udev trigger to finish, then puts the nvme module back into the system, reproducing the initial installation of the deb/udeb containing the nvme module 5) immediately triggers udev, which should load the nvme module when it sees the nvme pci device 6) wait 3 seconds for udev trigger to finish (plenty of time), and check if the nvme module was loaded this script reproduces the error every time, due to the stale kmod context. With a fixed udev, this should succeed in loading the nvme module. [Regression Potential] The most potential for regression with a fix to this involves slowing down udev due to validating the kmod context for every kmod load call. However, slightly higher performance does not make up for broken operation. [Other Info] This needs fixing upstream, which I'm in progress on. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1714505/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
