Re: multiple events

[David Brownell <david-b@pacbell.net>]

Andrew Morton wronte:
> Oliver Neukum wrote:
> > 
> > On Sonntag, 21. Januar 2001 13:29, Andrew Morton wrote:
> > > Oliver Neukum wrote:
> > > > Hi list,
> > > >
> > > > I was looking through the kmod code and was wondering about the context
> > > > /sbin/hotplug is run.
> > > >
> > > > It seems to be run in the context of keventd. Does this mean that there
> > > > can only be one instance of /sbin/hotplug at a time ?

The original code didn't have "keventd".  It allowed different
subsystems to establish that policy however they needed.

For example, "khubd" for USB would only make one call at a time;
there's no parallel enumeration, and disconnects are always
serialized.  (So USB only ran one at a time.)  And the "cardbus
watcher" threads would handle their own cardbus bridges.  (One
per slot -- often two slots per machine.)


> > > No, /sbin/hotplug is run asynchronously, so multiple instances
> > > can and will be run concurrently.  A fix exists, but I'm still
> > > trying to get my head around whether there's justification
> > > for asking for its inclusion.
> > 
> > Does this mean that "add" might race with "remove" ?
> 
> Yes, easily.

Originally, no -- because the thread which was enumerating
the adds/removes was the one that waited for the invocation
of hotplug to complete.  Remove processing wouldn't start
till after the add processing completed.


>      Cardbus devices can still generate several events
> quickly due to contact bounce.

Must they?  Software debouncing in drivers is hardly new.


> > On the other hand, if you go for serialisation, is there a possibilty of a
> > deadlock ?
> > device 1 -> hotplug -> module loaded -> device 2 registered -> hotplug ->
> > DEADLOCK

Maybe if you use locks to serialize, and do it incorrectly.
(Perhaps by accident ...)

The interesting cases involve situations where "device 2" is some
kind of logical device ... say a network device (dev 1 is a USB
or Cardbus network adapter), an emulated SCSI disk, printer, etc.

Network hotplugging has triggered more problems than USB or PCI,
and one of the problem scenarios related to the RTNL lock.  Some
network drivers used an initialization sequence that involves
(implicitly) getting that lock and then calling hotplug with it
held ... of course, the first thing hotplug needed to do was
get that lock, and that deadlocked.  As I understand, Alexey and
Andrew have resolved those network driver API problems cleanly,
but the fix isn't in 2.4.0 (it's in CVS somewhere).

That shows another class of potential hotplug problems, and the
SCSI folk seem to be aware of the risk there:  subsystems should
not just blindly call call_usermodehelper() and expect existing
APIs to be hotplug-safe.


> You need to be careful with deadlocks.  But it's OK with netdevices
> on cardbus and can probably be sorted out for other combinations.
> 
> Actually, global serialisation of hotplug events would be a good thing to have.
> I guess this could be done in userspace.

Serializing independent subsystems is typically NOT good; maintainable
code doesn't create needless dependencies.  And then there are the
performance issues; and the enabling of global deadlock.

Re-serializing in userspace, after discarding most of the essential
serialization data, isn't a simple problem.


> Which begs the question: why is the kernel running /sbin/hotplug at all?

One answer very much relates to the serialization guarantees
needed to reliably handle hotplugging.  For example, when the
hotplug agent software needs to access the device, and uses its
name, it's rather important to know that the (path?)name will be
usable, and will correspond to the correct device, while that
agent is doing its work.  Hotplugging subsystems can easily
provide such guarantees by (synchronously) calling hotplug; I
have a hard time seeing how they can be provided without the
assistance of the subsystem that's hotplugging.

Don't forget the "why was the original design changed" question!
That answer should be pretty informative too.


> It would be better if the strings were squirted out to a daemon across a
> pipe or whatever, I suspect.  I wasn't involved in those discussions - I
> may have missed something vital.
>
> Maybe /sbin/hotplug should just send a message to hotplugd and let
> hotplugd do all the serialisation?

How could the hotplug agent then have a guarantee that the device
names it's using to do its work are correct? 






_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel