Messages in this thread | | | From | Kay Sievers <> | Date | Wed, 3 Oct 2012 19:24:34 +0200 | Subject | Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() |
| |
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH <gregkh@linuxfoundation.org> 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
| |