lkml.org 
[lkml]   [2001]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] RFC: fix ethernet device initialization
    Jeff Garzik wrote:
    >
    > People from time to time point out a wart in ethernet initialization:
    >

    They sure do. You were away at the time, but I had a 94 file,
    140k patch late last year which fixed all this. It's
    at

    http://www.uow.edu.au/~andrewm/linux/netdevice.patch

    and the design doc is at

    http://www.uow.edu.au/~andrewm/linux/netdevice2.txt

    From a quick look, I think the only substantive difference
    here is that my `prepare_etherdev()' function allocates
    and reserves the device's name (eth0), but prevents it
    from being available in netdevice namespace lookups. This
    was done because lots of drivers wanted to do:

    init_etherdev(); (Replaced with prepare_etherdev())
    printk("%s: something", dev->name);

    The changes to dev.c and net_init.c were fairly subtle
    and took some thinking about - we should revisit them
    if you want to go ahead with this.

    The patch all worked OK, was back-compatible with unaltered
    drivers, and indeed altered all the drivers. But it kind of
    got lost. Too big, too late and dev_probe_lock() was there.

    Now, Arjan says that this race is causing oopses. This
    surprises me, because current kernels have the the dev_probe_lock()
    hack which I put in. This fixes the problem for PCI and Cardbus
    drivers. The ISA drivers generally use the dev->init() technique
    which is not racy. There isn't a lot left over. Arjan? Which driver?

    The other reason I'm surprised that it's causing oopses: most
    racy drivers do this:

    xxx_probe()
    {
    init_etherdev();
    <initialisation - takes 10s of milliseconds and can sleep>
    dev->open = xxx_open;
    return;
    }

    So the vastly most probably failure mode if the race occurs
    is this: the interface is opened while dev->open is NULL.
    This won't oops. Sure, the interface is screwed because
    the open() routine hasn't been called, but it should hang
    in there. A subsequent close() of the interface *will*
    call dev->close, and I guess the driver is likely to get
    upset if its close() routine is called without a corresponding
    open().

    Yes, we can fix this if we want, and kill off dev_probe_lock().
    It'll only take a few days. Do we want? If not, we can
    extend the dev_probe_lock() thing to cover probes for
    other busses. USB, I guess.


    -
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:0.024 / U:63.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site