Opened 20 years ago
Closed 20 years ago
#864 closed defect (fixed)
Races with device creation when udev is used with a modular kernel
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Book | Version: | SVN |
Severity: | critical | Keywords: | |
Cc: |
Description
It is a known fact that device creation with udev in response to hotplug enevts (those generated after modules load) is asynchronous. So the device creation happens a bit after the modprobe command finishes.
A result is that one can no longer assume that when a module finished loaded (i.e., the modprobe command returned) it is usable. This assumption fails because the device might have not been created yet (i.e., race of device creation vs its use).
A known victim is the ALSA initscript in BLFS if the soundcard module (e.g., snd-fm801) is loaded by hotplug. There may be others.
An upstream "wisdom" is to abandon the fundamental concept of executing initscripts synchronously and sequentially. One has to put handlers into /etc/dev.d instead. However, this "solution" doesn't work.
First, these handlers are not called by udevstart, so people who compiled snd-fm801 as a non-module need an initscript, not a /etc/dev.d handler, to restore volumes. We have to support two cases instead of one.
Then, there is no documented way (see undocumented way below) to _wait_ (as opposed to putting a handler) for completion of the process of creation of all devices that should be created as a result of loading a module. The upstream "wisdom" is: you should not need to wait, you should always put a handler -- but this works only when a device name is known, unlike the case when the module is probed by coldplug scripts.
All of the above means that there is _no_ documented way to safely use udev + modules. So we should either drop udev, or completely drop support for modular kernels, or accept a hack below.
The hack is based on two undocumented facts:
1) Creation of sysfs entries is synchronous, i.e. all of them are guaranteed to exist when modprobe finishes 2) udevstart is synchronous, i.e. all device nodes corresponding to existing sysfs entries are guaranteed to exist when udevstart finishes
So I propose to add a second call to udevstart to the end of the start section of the hotplug initscript, to create all device nodes corresponding to modules loaded by hotplug. Of course it should be surrounded by the check if /sbin/udevstart is executable, and a pointer to this bug must be in the comments above this hack.
This fixes a problem with ALSA initscript and in fact all races caused by modprobe commands in the hotplug initscript.
It doesn't fix the possible problem with other applications who probe the module themselves (DRI/Xorg? can't check) and expect the devices to be immediately usable. This problem is unfixable and must be documented in the LFS book.
Oh, there is! Create a wrapper around modprobe that calls udevstart after the real modprobe :)
Change History (2)
comment:1 by , 20 years ago
Version: | CVS → SVN |
---|
comment:2 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Marking this as fixed. This is notated in the udev explanation in the book, and the system builder can address however he sees fit.