From: Andrew Morton <andrewm@uow.edu.au>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Linux Knernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>,
Alan Cox <alan@redhat.com>, "David S. Miller" <davem@redhat.com>,
netdev@oss.sgi.com, Arjan van de Ven <arjan@fenrus.demon.nl>
Subject: Re: [PATCH] RFC: fix ethernet device initialization
Date: Wed, 07 Mar 2001 23:13:04 +0000 [thread overview]
Message-ID: <3AA6C080.99D35298@uow.edu.au> (raw)
In-Reply-To: <3AA6A570.57FF2D36@mandrakesoft.com>
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.
-
next prev parent reply other threads:[~2001-03-07 23:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-07 21:17 [PATCH] RFC: fix ethernet device initialization Jeff Garzik
2001-03-07 21:23 ` Jeff Garzik
2001-03-07 21:41 ` Arjan van de Ven
2001-03-07 22:16 ` Jeff Garzik
2001-03-07 23:13 ` Andrew Morton [this message]
2001-03-07 23:23 ` Alan Cox
2001-03-08 17:35 ` Jes Sorensen
2001-03-11 3:25 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AA6C080.99D35298@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=alan@redhat.com \
--cc=arjan@fenrus.demon.nl \
--cc=davem@redhat.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).