On Tue, Dec 20, 2011 at 14:31, Andy Whitcroft <apw@xxxxxxxxxxxxx> wrote: > On Sat, Dec 17, 2011 at 07:15:00PM +0100, Kay Sievers wrote: >> The patch looks sensible, but I haven't really wrapped my head around >> if we really should make the TIMEOUT= handling even more special here. >> I rather see the firmware loading model fixed for the affected >> drivers, as I think it is very wrong, for many other reasons too, what >> they do here. > > I believe that the change makes TIMEOUT= handline consistantly special, > ie. it always triggers expedited handling regardless of whether we are > running normally or in the process of exiting. Plus, by handling these > events we can avoid deadlocking the modprobe for these bad drivers. As mentioned earlier, at this point, I rather remove the entire TIMEOUT handling from udev to reach consistency, than make it even more special. It's not a proper facility, it's a left-over from the time the entire hotplug stuff was not working at all. There are no guarantees that asynchronous events will ever be handled in a certain time frame. Everything should have a timeout, and we should handle that as good as we can, but we need to avoid synchronous kernel dependencies on userspace. And kernel drivers should not get away these days with dirty hacks like this. Since a while we refuse to work around such broken kernel behaviour in userspace, for the reason to put the blame and focus where it belongs: at the bug and not at the workaround. And what you analysed here is a kernel bug, not a userspace one. And I still think that depending on a userspace transaction in module init is just terribly broken. If udev is not running properly, modprobe will just hang until a timeout is reached, and that is just not how things should work. I think, that supporting event inter-dependencies that way just asks for trouble in the long run. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
