Patch against 2.6.0 to fix the problem of being unable to load the ethernet
driver because of reference's still being held. The problem reference's
are from IPV6 network discovery packets that get captured by the af_packet protocol
and queued onto a socket queue (which may never drain). The route dst entries
in the skbuff get clone'd and won't be freed until the socket read.
diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c
--- a/net/packet/af_packet.c Tue Dec 23 14:25:10 2003
+++ b/net/packet/af_packet.c Tue Dec 23 14:25:10 2003
@@ -246,6 +246,10 @@
if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL)
goto oom;
+ /* drop any routing info */
+ dst_release(skb->dst);
+ skb->dst = NULL;
+
spkt = (struct sockaddr_pkt*)skb->cb;
skb_push(skb, skb->data-skb->mac.raw);
@@ -486,6 +490,9 @@
skb_set_owner_r(skb, sk);
skb->dev = NULL;
+ dst_release(skb->dst);
+ skb->dst = NULL;
+
spin_lock(&sk->sk_receive_queue.lock);
po->stats.tp_packets++;
__skb_queue_tail(&sk->sk_receive_queue, skb);
On Tue, 23 Dec 2003 14:29:31 -0800
Stephen Hemminger [off-list ref] wrote:
Patch against 2.6.0 to fix the problem of being unable to load the
ethernet driver because of reference's still being held. The
problem reference's are from IPV6 network discovery packets that get
captured by the af_packet protocol and queued onto a socket queue
(which may never drain). The route dst entries in the skbuff get
clone'd and won't be freed until the socket read.
Are you going to add such code to RAW, UDP, TCP, etc. etc.?
I understand the problem, but the point I'm making here is that
I see nothing which makes it specific to AF_PACKET.
This brings us back to an old and sore topic, which is the
dst_dev_event() code in net/core/dst.c, have you had a look
at that?
On Tue, 23 Dec 2003 14:38:32 -0800
"David S. Miller" [off-list ref] wrote:
On Tue, 23 Dec 2003 14:29:31 -0800
Stephen Hemminger [off-list ref] wrote:
quoted
Patch against 2.6.0 to fix the problem of being unable to load the
ethernet driver because of reference's still being held. The
problem reference's are from IPV6 network discovery packets that get
captured by the af_packet protocol and queued onto a socket queue
(which may never drain). The route dst entries in the skbuff get
clone'd and won't be freed until the socket read.
Are you going to add such code to RAW, UDP, TCP, etc. etc.?
They don't have the problem because they don't go through the netdev_queue_xmit_nit
code path. Audited all calls to dev_add_packet and AF_PACKET is the only
one that I found that could potentially register for ptype_all.
The same thing could happen through the loopback device, though.
But the loopback device can never be unloaded so it doesn't really
hurt anything.
I understand the problem, but the point I'm making here is that
I see nothing which makes it specific to AF_PACKET.
AF_PACKET is the only one (today) that can take packets intended
for a real device and end up queueing them to user space.
This brings us back to an old and sore topic, which is the
dst_dev_event() code in net/core/dst.c, have you had a look
at that?
Yes, I did look at that but it wasn't the problem here.
On Tue, 23 Dec 2003 15:11:54 -0800
Stephen Hemminger [off-list ref] wrote:
On Tue, 23 Dec 2003 14:38:32 -0800
"David S. Miller" [off-list ref] wrote:
quoted
Are you going to add such code to RAW, UDP, TCP, etc. etc.?
They don't have the problem because they don't go through the netdev_queue_xmit_nit
code path. Audited all calls to dev_add_packet and AF_PACKET is the only
one that I found that could potentially register for ptype_all.
The same thing could happen through the loopback device, though.
But the loopback device can never be unloaded so it doesn't really
hurt anything.
I see, thanks for the clarification.... I have an idea, let me think
about this a little bit more.
On Tue, 23 Dec 2003 14:29:31 -0800
Stephen Hemminger [off-list ref] wrote:
Patch against 2.6.0 to fix the problem of being unable to load the
ethernet driver because of reference's still being held. The
problem reference's are from IPV6 network discovery packets that get
captured by the af_packet protocol and queued onto a socket queue
(which may never drain). The route dst entries in the skbuff get
clone'd and won't be freed until the socket read.
Ok, I've applied this patch, it's the best solution at this time.
Thanks.