From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sun, 21 Jan 2001 18:37:02 +0000 Subject: Re: multiple events Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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