> Hi David,
quoted text
>
> 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.

quoted text
> > 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.

quoted text
> 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


-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/