On 29/11/10 13:39, Jozsef Kadlecsik wrote:
On Mon, 29 Nov 2010, Pablo Neira Ayuso wrote:
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.
So Jan has got right: if the process which initiated the dumping is
suspended and locking is used, then the suspended process locks out all
other processes.
Suspending the process in the middle of the dump is a strange scenario.
If you did this accidentally, then you can notice it since you hit
EAGAIN over and over again, so you can kill the dumper manually.
A user-space process that stops in the middle of a dump must be
considered buggy, you have to fix your user-space program.
This does not affect packet processing, only user-space interaction.
--
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
