* Re: multiple events
2001-01-21 12:17 multiple events Oliver Neukum
2001-01-21 12:29 ` Andrew Morton
2001-01-21 12:33 ` Oliver Neukum
@ 2001-01-21 12:49 ` Andrew Morton
2001-01-21 18:37 ` David Brownell
3 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2001-01-21 12:49 UTC (permalink / raw)
To: linux-hotplug
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 ?
> >
> > 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. Cardbus devices can still generate several events
quickly due to contact bounce.
> 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
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.
Which begs the question: why is the kernel running /sbin/hotplug at all?
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?
_______________________________________________
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: multiple events
2001-01-21 12:17 multiple events Oliver Neukum
` (2 preceding siblings ...)
2001-01-21 12:49 ` Andrew Morton
@ 2001-01-21 18:37 ` David Brownell
3 siblings, 0 replies; 5+ messages in thread
From: David Brownell @ 2001-01-21 18:37 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 5+ messages in thread