On 27/11/10 21:42, Jozsef Kadlecsik wrote:
On Sat, 27 Nov 2010, Jan Engelhardt wrote:
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().
In netlink_dump() after the call to cb->dump, you can see the call to
skb_queue_tail. So the message is queued.
Where the looping happens, I do not know. Some socket magic?
1) you send a NLM_F_DUMP request.
2) the kernel fills one skb and enqueue it into the socket buffer.
3) the process invokes recvmsg(), it gets the datagram, then go back to
step 2).
Thus, the dump only consumes 1 memory page per recv() invocation. That's
the magic.
--
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
