netdev
[Top] [All Lists]

Re: modular net drivers

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: modular net drivers
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 20 Jun 2000 00:58:16 +0000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
References: <394E2616.C25F8376@xxxxxxxxxx> <Pine.LNX.4.10.10006192011230.26261-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Donald Becker wrote:
> 

Hello, Donald.

> On Mon, 19 Jun 2000, Andrew Morton wrote:
> 
> > As you may have noticed, Al Viro is running around the kernel getting
> > rid of MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT.  His long-term plan
> > is to remove MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT completely.
> > I'm looking into the changes required for the net drivers.
> 
> Hmmm, this is curious.
> Should not the "feature freeze" phase come well after the "interface freeze"?
> This is pretty obviously an interface change.

Yes, I find it amusing that when something stable is imminent, people
start madly running around cleaning up stuff that should have been done
months/years ago.  Oh well.  Better than not doing it.

Linus' attitude is that interface changes should go into 2.4 even if
they're large/risky, because he seeks to minimise the differences
between 2.4 and 2.5, so problem fixes can be fed between the two.  This
is unconventional and useful.


> > - All 2.4-only netdrivers can have all their MOD_DEC and MOD_INC calls
> >   removed.  All that twisty logic to keep track of the counts can be
> >   tossed.  A single
> >
> >       SET_NETDEVICE_OWNER(dev);
> 
> "Twisty logic"?  Most of the drivers have straight-forward use counts.

They used to, but it was risky.

The problem with a simple MOD_INC_USE_COUNT at the end of open() is that
the preceding kmalloc()'s can sleep while the module refcount is zero,
exposing an opportunity for the module to be unloaded while running.

So the "fix" was to move the MOD_INC_USE_COUNT to the top of open() and
to do complementary MOD_DEC calls wherever the open() method takes an
error path.  It's pretty stinky and still doesn't stop the races.

> How is this new method any simpler?  If anything, it seems to be more
> complex without any obvious benefit.

Well, even if it wasn't for the race-avoidance issue, it's always nice
to suck out duplicated code and put it in one place.

<Prev in Thread] Current Thread [Next in Thread>