[lkml]   [2012]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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 <> 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

    > 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.


     \ /
      Last update: 2012-10-03 20:01    [W:0.025 / U:2.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site