Messages in this thread | | | Date | Wed, 07 Mar 2001 23:13:04 +0000 | From | Andrew Morton <> | Subject | Re: [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/
| |