On Wed, Oct 3, 2012 at 6:57 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> It's the same in the current release, we still haven't wrapped our >> head around how to fix it/work around it. > > Ick, as this is breaking people's previously-working machines, shouldn't > this be resolved quickly? Nothing really "breaks", It's "slow" and it will surely be fixed when we know what's the right fix, which we haven't sorted out at this moment. > module_init() can do lots of "bad" things, sleeping, asking for > firmware, and lots of other things. To have userspace block because of > this doesn't seem very wise. Not saying that it is right or nice, but it's the kernel itself that blocks. Run init=/bin/sh and do a modprobe of one of these drivers and it hangs un-interruptible until the kernel's internal firmware loading request times out, just because userspace is not there. > But previously this all "just worked" as we ran 'modprobe' in a new > thread/process right? No, we used to un-queue events which had a timeout specified in the environment, that code caused other issues and was removed. > it can do without worrying about stopping anything else in the system that might > want to happen at the same time (like load multiple modules in a row). It should not be an issue, the serialization is strictly parent <-> child, everything else runs in parallel. >> If that unfortunate module_init() lockup can't be solved properly in >> the kernel, we need to find out if we need to make the modprobe >> handling in udev async, or let firmware events bypass dependency >> resolving. As mentioned, we haven't decided as of now which road to >> take here. > > It's not a lockup, there have never been rules about what a driver could > and could not do in its module_init() function. Sure, there are some > not-nice drivers out there, but don't halt the whole system just because > of them. It is a kind of lock up, just try modprobe with the init=/bin/sh boot. > I recommend making module loading async, like it used to be, and then > all should be fine, right? That's the current idea, and Tom is looking into it how it could look like. I also have no issues at all if the kernel does load the firmware from the filesystem on its own; it sounds like the simplest and most robust solution from a general look at the problem. It would also make the difference between in-kernel firmware and out-of-kernel firmware less visible, which sounds good. Honestly, requiring firmware-loading userspace-transactions to successfully link a module into the kernel sounds like a pretty bad idea to start with. Unlike module loading which needs the depmod alias database and userspace configuration; with firmware loading, there is no policy involved where userspace would add any single additional value to that step. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
