On Saturday 2010-11-27 18:04, Jozsef Kadlecsik wrote: > >AFAIK when the kernel dumps and the skb is full, it's not returned >directly to the userspace but first enqueued. I don't recognize that inside the code however. In netlink_dump(), there is the cb->dump call. There are no loops inside this function. Neither are there in the two parents, netlink_dump_start() and netlink_recvmsg(). The queueing behavior you mention I only see when the kernel autonomously sends packets that have not been explicitly requested by userspace. >* let there be a list of 6 entries of data, ABCDEF >* proc A starts a dump, and kernel enqueues the messages, which > cover all entries. Given a big enough ruleset, it won't cover all of them. >And if the userspace listener is too slow/not ready to receive the netlink >messages from the queue, then the queue can get full and messages will be >lost. If that was the case, we would have seen truncated ct dumps already. Because the standard queue is just something like 124KB or so, that would be a mere ~40 fully-stuffed packets in the queue, and people certainly have more than 40, for safety, even more than 1000 connections live at a time, so somebody has already run into a queue overflow, iff things were queued in the first place. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
