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. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- 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
