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

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

Hello!

> I get your point and I see the value. Unfortunately, probably due to
> lack of documentation, this feature isn't used by any applications I
> know of.

Well, tc was supposed to use it, but this did not happen and
it remained deficient.


> We even put in the hacks to make identification of own caused
> notifications easier by storing the netlink pid of the originator in
> the notification message.

Actually, it was supposed to be done everywhere, but originator info
did not propagate deep enough in many cases, especially in IPv6.
So, this is not a hack, it is a good work. :-)


BTW I have just remembered why it was especially important,
this should be documented as well.

Each socket, which subscribes to multicasts becomes sensitive
to rcvbuf overflows. F.e. when you do control operations on a socket,
which is subscribed to multicasts, the response can be lost in stream
of events and -ENOBUFS generated instead. If it is a daemon, it can resync
the state, but if it is a simple utility, it cannot recover.

Probably, unicasts sent due to NLM_F_ECHO should somehow override
rcvbuf limits.

This reminded me about a capital problem, found by openvz people.
Frankly speaking, I still have no idea how to repair this, probably you
will find a solution.

Look: while a dump, skb allocation can fail (because of many reasons,
the most obvious is that rcvbuf space was eaten by multicasts).
But error is not reported! Oops. The worst thing is that even if an error
is reported, iproute would ignore it.

Alexey