> Those are the places that are bugs. Setting skb->sk=NULL is a bad thing to be doing
> in 2.1.x (it made sense in 2.0). Probably we need skb_disown(skb) to be sure
> behaviour is always right
>
> > I.e., if the socket has refused to queue the skb, the skb should remain
> > unassigned until another socket queues it.
>
> Right now it may seem to, but the logical extension to the socket filters is
> to be able to bounce buffers through secondary queues to user space
> daemons on rule matches (like Digitals firewall) at that point we need to
> account first.
Hi Alan,
Defining an skb_disown() routine sounds reasonable, though I still think it
doesn't make sense to set the owner until you're sure the socket is going to
accept the packet. Since the code in question is running from a BH handler, I
don't think you're going to do anything in user space from the current context.
The main thing I'd like to ensure is that the skb is not owned following an
error return from the socket queueing code, so that it can be tried again for
the next socket. Since it's a fair amount of work to allocate and copy an skb,
it would improve multicasting performance to pass the socket along rather than
freeing it after a queueing failure.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu