Hi Walter,

On Wed, Sep 14, 2011 at 11:55:08PM -0400, Walter Dnes wrote:

[snip]

>   Gentoo has /bin/busybox as part of the default system.  There is also
> an option to build busybox with libraries statically linked.  IANAPP
> (I Am Not A Professional Programmer), but I can do quite a bit of bash
> scripting etc.  In Gentoo, the user generally knows what peripherals he
> has permanently connected to the machine.  Plus you'll get the usual USB
> keys and external drives being hooked up occasionally.
> 
>   If mdev can replace udev a lot of Gentoo users would be very happy.
> You might even have to start a separate "mdev-users" list <G>.

I haven't seen a mention of the inherently racy nature of the hotplug 
mechanism on which mdev relies. Below is an explanation taken from 
http://www.kernel.org/doc/pending/hotplug.txt (down at the moment).

<quote>

A note about race conditions (or "why bother with netlink?"):
=============================================================

Some simple systems (such as embedded systems) scan sysfs once at boot time
to populate /dev, and ignore any hotplug events.  Scanning again to probe for
new devices is a workable option (as long as mknod failing because the
device already exists isn't considered an error condition). 

Systems that actually support hotplug should start to handle hotplug events
_before_ scanning sysfs for existing devices, to ensure that that any devices
added during the scan reliably have a /dev entry created for them.

Devices removed while scanning /sys may still result in leftover /dev nodes
after the scan.  The race is that the scanning process may read the "dev"
entry for a device from sysfs, be interrupted by a hotplug event which 
attempts to remove that device, and then the scanning process resumes and 
creates the device node for the already-removed device.  In theory this is no 
more of a security concern than having a statically allocated /dev (the device 
node will return -ENODEV to programs that try to use it) but, it's untidy.

In theory, transient devices (which are created and removed again almost
instantly, which can be caused by poorly written drivers that fail their 
device probe) could have similar "leftover" /dev entries from the 
/sbin/hotplug mechanism.  (If two processes are spawned simultaneously, which 
one completes first is not guaranteed.)  This is not common, but theoretically 
possible.

These sort of races are why the netlink mechanism was created.  To avoid
such potential races when using netlink, instead of reading each "dev" entry,
fake "add" events by writing to each device's "uevent" file in sysfs.  This
filters the sequencing through the kernel, which will not deliver an "add"
event packet to the netlink process for a device that has been removed.

Note also that on very large mainframe systems, /sbin/hotplug can potentially
fork bomb the system during system bringup.

</quote>

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to