multiple events
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 ?
TIA
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Oliver Neukum
Hi list,
I was looking through the kmod code and was wondering about the context
/sbin/hotplugis run.It seems to be run in the context of keventd. Does this mean that there can only be one instance of
/sbin/hotplugat 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.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Andrew Morton
Quoted 5 lines · Oliver Neukum
Hi list,
I was looking through the kmod code and was wondering about the context
/sbin/hotplugis run.
Quoted 7 lines
Quoted 2 lines
It seems to be run in the context of keventd. Does this mean that there can only be one instance of
/sbin/hotplugat a time ?No,
/sbin/hotplugis 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" ?
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
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Oliver Neukum
Quoted 9 lines · Andrew Morton
Quoted 7 lines · Oliver Neukum
Hi list,
I was looking through the kmod code and was wondering about the context
/sbin/hotplugis run.It seems to be run in the context of keventd. Does this mean that there can only be one instance of
/sbin/hotplugat a time ?
Quoted 6 lines
Quoted 4 lines
No,
/sbin/hotplugis 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.
Quoted 4 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Andrew Morton wronte:
Quoted 11 lines
Quoted 10 lines · Oliver Neukum
Quoted 8 lines · Andrew Morton
Quoted 7 lines · Oliver Neukum
Hi list,
I was looking through the kmod code and was wondering about the context
/sbin/hotplugis run.It seems to be run in the context of keventd. Does this mean that there can only be one instance of
/sbin/hotplugat 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.)
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
No,
/sbin/hotplugis 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.
Quoted 2 lines
Cardbus devices can still generate several events
quickly due to contact bounce.
Must they? Software debouncing in drivers is hardly new.
Quoted 4 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 1 line
Which begs the question: why is the kernel running
/sbin/hotplugat 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.
Quoted 6 lines
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/hotplugshould 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel