Re: [PATCH 1/4] [NETLINK]: Handle NLM_F_ECHO in netlink_rcv_skb()

[Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>]

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