[net] protecting interfaces from races between control and data ?

[Scott Long]

On Aug 7, 2013, at 10:16 PM, Warner Losh <imp at bsdimp.com> wrote:

> 
> On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> 
>> .. and I bet it's not a design pattern, and this is total conjecture on my part:
>> 
>> * the original drivers weren't SMP safe;
>> * noone really sat down and figured out how to correctly synchronise
>> all of this stuff;
>> * people did the minimum amount of work to keep the driver from
>> immediately crashing, but didn't really think things through at a
>> larger scale.
>> 
>> Almost every driver is this way Luigi. :-)
> 
> Most of the drivers in the three don't support hardware that performs well enough for this to be a problem. :) Any driver that's still around from the pre-locking days can easily saturate the lines (or the hardware) on today's (and even yesterday's hardware).
> 
> All the rest have come up with different ways to cope…
> 

Not really.

So the typical pattern is:

foo_rxeof()
{
    ….
    FOO_UNLOCK(sc);
    ifp->if_input(ifp, m);
    FOO_LOCK(sc);
    ….
}

Grepping for an approximation of this pattern:

[nflx1] ~/svn/head/sys/dev% grep -r -B 5 if_input * | grep -i UNLOCK | cut -d '/' -f 1
ae
age
alc
ale
an
an
bce
bfe
bge
bm
cadence
cas
cas
dc
de
e1000
e1000
e1000
ed
ep
et
ex
fe
fxp
gem
gxemul
hme
ie
ixgb
ixgbe
ixgbe
jme
le
le
lge
mge
msk
msk
my
nfe
nfe
nge
nve
pcn
pdq
re
sbni
sf
sge
sis
sk
sk
sn
snc
ste
stge
ti
tl
tsec
tx
txp
usb
usb
vge
virtio
vr
vte
vx
wb
wl
xe
xl

Sure a lot of these are very legacy.  But there's a lot in here's that are not.  bge, bce, e1000, ixgbe, virtio, etc, probably more that I'm not catching in this quick pass.

Scott