Hello! > Makes sense, especially for auto generated handles. I've been listening > to the notifications on a separate socket for this purpose.
That's... complicated. But cool. :-) > It does make sense, the way it has been implemented if at all is > creepy. Even worse, IPv6 is using current->pid, some other code > has been using the pid from NETLINK_CREDS() :-) Yeah, some time ago I sent a path replacing those with 0, but apparently I forgot to grep IPv6. And did not even search for NETLINK_CREDS(). > when receiving multicasts. Also because some of the multicast > code is buggy and provides the pid of the requestor's socket to > netlink_broadcast() leading to excluding that socket. Actually, it was the idea. If requestor asked NLM_F_ECHO and subscribed to muticasts, it suppresses double notifications. If it did not ask NLM_F_ECHO, he is not interested in results, he knows what's going on without this. F.e. it was used by my implementation in gated: it did not set either NLM_F_ECHO or even NLM_F_ACK. And when making massive batch updates, it received nothing back: only errors and updates made by someone else. > I'm not sure I understand this correctly, if rcvbuf space was eaten > by multicasts subsequent recvmsg() will follow invoking netlink_dump() > again and the dump continues. Indeed. I forgot how it works. :-) I understood what is happening there. sock_rmalloc() fails not due to rcvbuf, but because of global resource limiting. Grr... it does not look solvable. Luckily, in normal kernel this can happen only if 0-order GFP_KERNEL allocation fails. Not impossible with oom_killer, but it definitely moves the status of the problem to marginal. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
