* Alexey Kuznetsov <[EMAIL PROTECTED]> 2006-08-11 19:35 > Well, tc was supposed to use it, but this did not happen and > it remained deficient.
Makes sense, especially for auto generated handles. I've been listening to the notifications on a separate socket for this purpose. It would make sense however to extend a wait_for_ack() function and report back and eventual echoed objects to have a blocking operation as well. > 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. :-) 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() :-) > 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. Yes, for that reason it is recommended to use a separate socket 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. > 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. 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. - 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
