SOCK_PACKET bug with ETH_P_ALL?

Oliver Jowett (oliver@hydra)
Thu, 12 Sep 1996 17:00:48 +1200 (NZST)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--2072122914-1369423519-842504448=:308
Content-Type: TEXT/PLAIN; charset=US-ASCII

I run 3 diald processes on a Linux box sitting on a pretty busy ethernet.
I recently noticed that each of these dialds was using 1-3% cpu time, even
when the proxies were idle. Turning on promisc mode on eth0 pushed that
through the roof. 'strace'ing a diald produced results along the line of:

select(100, [1 2 4], NULL, NULL, {0, 990000}) = 1 (in [2], left {0, 710000})
recvfrom(2, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 142
time(NULL) = 842498155
time(NULL) = 842498155
select(100, [1 2 4], NULL, NULL, {0, 710000}) = 1 (in [2], left {0, 520000})
recvfrom(2, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 111
time(NULL) = 842498155
time(NULL) = 842498155
select(100, [1 2 4], NULL, NULL, {0, 520000}) = 1 (in [2], left {0, 190000})
recvfrom(2, "\377\377\377\377\377\377\0\200\243"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 110
time(NULL) = 842498155
time(NULL) = 842498155

(etc)

It looks like the snoop device is still receiving packets from eth0,
despite the fact that descriptor 2, a SOCK_PACKET socket, has successfully
called bind() to bind to the slip proxy.

Looking in net/core/dev.c, it looks like net_bh is forwarding packets that
it shouldn't - it forwards packets to a packet-capture function with
protocol ETH_P_ALL regardless of the value of ptype->dev.

I changed this to check the device, and the dialds magically went to 0%
cpu :) ... a patch is attached (against 2.0.14, but I didn't see any
changes to this bit of code in 15-18). I did a grep for ETH_P_ALL and the
kernel code doesn't seem to use it, so hopefully this doesn't break
anything else.

Is it worth moving the ptype_all list for sniffers bound to a specific
device into the device struct? The current setup means that such a sniffer
will cause a check of the entire ptype_all list for every packet received
on _any_ device - which could become a problem with eg. multiple dialds
(large ptype_all list) and a busy ethernet.

Oliver.
(oliver@sa-search.massey.ac.nz, in case sendmail decides to mangle it)

--2072122914-1369423519-842504448=:308
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=netbh-patch
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.91.960912170048.308A@sa-search.massey.ac.nz>
Content-Description: linux/net/core/dev.c patch

LS0tIGxpbnV4L25ldC9jb3JlL2Rldi5jLm9sZAlUaHUgU2VwIDEyIDE1OjE4
OjM3IDE5OTYNCisrKyBsaW51eC9uZXQvY29yZS9kZXYuYwlUaHUgU2VwIDEy
IDE1OjI4OjEzIDE5OTYNCkBAIC02NTQsMTMgKzY1NCwxNyBAQA0KIAkJcHRf
cHJldiA9IE5VTEw7DQogCQlmb3IgKHB0eXBlID0gcHR5cGVfYWxsOyBwdHlw
ZSE9TlVMTDsgcHR5cGU9cHR5cGUtPm5leHQpDQogCQl7DQotCQkJaWYocHRf
cHJldikNCisgICAgICAgICAgICAgICAgICAgICAgICAvKiBNYWtlIHN1cmUg
d2Ugb25seSBwYXNzIG9uIHBhY2tldHMgZm9yIHRoZSByaWdodCBkZXZpY2Ug
Ki8NCisJCQlpZiAoIXB0eXBlLT5kZXYgfHwgcHR5cGUtPmRldj09c2tiLT5k
ZXYpDQogCQkJew0KLQkJCQlzdHJ1Y3Qgc2tfYnVmZiAqc2tiMj1za2JfY2xv
bmUoc2tiLCBHRlBfQVRPTUlDKTsNCi0JCQkJaWYoc2tiMikNCi0JCQkJCXB0
X3ByZXYtPmZ1bmMoc2tiMixza2ItPmRldiwgcHRfcHJldik7DQotCQkJfQ0K
LQkJCXB0X3ByZXY9cHR5cGU7DQorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBpZihwdF9wcmV2KQ0KKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgew0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdHJ1Y3Qgc2tfYnVmZiAqc2tiMj1za2JfY2xvbmUoc2tiLCBH
RlBfQVRPTUlDKTsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaWYoc2tiMikNCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBwdF9wcmV2LT5mdW5jKHNrYjIsc2ti
LT5kZXYsIHB0X3ByZXYpOw0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHRf
cHJldj1wdHlwZTsNCisgICAgICAgICAgICAgICAgICAgICAgICB9DQogCQl9
DQogCQkNCiAJCWZvciAocHR5cGUgPSBwdHlwZV9iYXNlW250b2hzKHR5cGUp
JjE1XTsgcHR5cGUgIT0gTlVMTDsgcHR5cGUgPSBwdHlwZS0+bmV4dCkgDQo=
--2072122914-1369423519-842504448=:308--