> Hi David, > > Thanks for your quick reply. > > > If that were true, anyone who could send those packets to your > > machine would > > be able to cause the system to hang too. > > You're right to say that :) > > > Perhaps you are feeding the packets > > back in at too high a layer. > > Not really. In fact, I pass the packet back to the "lower layer" again > by calling netif_receive_skb(). Note that packets can go in a loop > here. To avoid queuing the same packets repeatedly, the module "marks" > them the first time they are queued. Marked packets are simply > NF_ACCEPT'ed by the module hook and therefore are propagated up the > netfilter chain.
So then there is no reason there should be any problem if the packets are fed after the socket is destroyed. I would try to figure out why something that should not give you a problem is giving you a problem. > > What object is this queue logically associated with? If the socket, you > > should probably hook 'release' so you can purge the queue when > > the socket is > > removed. > The queue is not associated with the socket. It is independent and is > meant just for the module to use for queuing packets that are supposed > to be delayed. But for each packet in this queue, there is an > associated kernel timer. Once this timer expires, the associated > packet is fed into the netif_receive_skb(). So what exactly goes wrong then? This approach sounds bulletproof. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/