lkml.org 
[lkml]   [2014]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC v2 3/6] kthread: warn on kill signal if not OOM
    Hello,

    On Tue, Sep 09, 2014 at 03:26:02PM -0700, James Bottomley wrote:
    > > We no longer report back error on probe failure on module load.
    >
    > Yes, we do; for every probe failure of a device on a driver we'll print
    > a warning (see drivers/base/dd.c). Now if someone is proposing we
    > should report this in a better fashion, that's probably a good idea, but
    > I must have missed that patch.

    We can do printks all the same from anywhere. There's nothing special
    about printing from the module loading thread. The only way to
    actually take advantage of the synchronisity would be propagating
    error return to the waiting issuer, which we used to do but no longer
    can.

    > > It
    > > used to make sense to indicate error for module load on probe failure
    > > when the hardware was a lot simpler and drivers did their own device
    > > enumeration. With the current bus / device setup, it doesn't make any
    > > sense and driver core silently suppresses all probe failures. There's
    > > nothing the probing thread can monitor anymore.
    >
    > Except the length of time taken to probe. That seems to be what systemd
    > is interested in, hence this whole thread, right?

    No, systemd in this case isn't interested in the time taken to probe
    at all. It is expecting module load to just do that - load the
    module. Modern userlands, systemd or not, no longer depend on or make
    use of the wait.

    > But that's nothing to do with sync or async. Nowadays we register a
    > driver, the driver may bind to multiple devices. If one of those
    > devices encounters an error during probe, we just report the fact in
    > dmesg and move on. The module_init thread currently returns when all
    > the probe routines for all enumerated devices have been called, so
    > module_init has no indication of any failures (because they might be
    > mixed with successes); successes are indicated as the device appears but
    > we have nothing other than the kernel log to indicate the failures. How
    > does moving to async probing alter this? It doesn't as far as I can
    > see, except that module_init returns earlier but now we no longer have
    > an indication of when the probe completes, so we have to add yet another
    > mechanism to tell us if we're interested in that. I really don't see
    > what this buys us.

    The thing is that we have to have dynamic mechanism to listen for
    device attachments no matter what and such mechanism has been in place
    for a long time at this point. The synchronous wait simply doesn't
    serve any purpose anymore and kinda gets in the way in that it makes
    it a possibly extremely slow process to tell whether loading of a
    module succeeded or not because the wait for the initial round of
    probe is piggybacked.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2014-09-10 01:21    [W:4.134 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site