some issues with rtnl_link_change waiting for completion

[Thomas Graf]

On Wed, Jan 11, 2012 at 12:28:18PM +0100, Arnaud Mouiche wrote:
> Hello,
> 
> first, description of my setup:
> - using latest availble git sources (commit
> 4a7791eca1268e24225c33ed1c00c140a14cd955)
> - linux 2.6.35 on a i686 (virtual box)
> 
> - ethernet link eth0 down when starting my application
> - vlan on eth0 already set (called eth0.10)
> - lo interface down
> 
> my program do:
> - do "nl_socket_add_membership(sock, RTNLGRP_LINK ); " to receive
> notifications of interface going done / up
> - do "nl_socket_disable_seq_check(sk);" also allow event packets
> with sequence = 0 to be received
> - do" nl_socket_modify_cb" to set an own callback on link change
> notifications
> 
> - set link up on eth0 (rtnl_link_change)
> - set link up on lo
> - browse the list of link address (rtnl_addr_alloc_cache)
> 
> 
> The issue is that the browse of link address shows no result at all.
> 
> Running the program with NLDBG=4 and NLCB=debug shows that "setting
> eth0 up" is not waiting for receiving a  "<route/link::new>" ack,
> but exit at the first <route/link::new> event, received due to
> "nl_socket_add_membership"
> 
> there is no wait of a particular sequence (the one corresponding to
> our <route/link::new> sent to the kernel).
> if "nl_socket_disable_seq_check(sk)" is not used, the wait_ack
> failed because of an error detected.
> 
> consequently, future commands also failed because of other
> <route/link::new> events (queued because of the vlan state change
> when changing the eth0 one), or because queued events with sequences
> will be incorrects.
> 
> 
> Questions:
> - Does it means that we can't use the same "struct nl_sock" to
> perform event notification and link configuration at once ?

Yes. Unless you want to do the demuxing yourself. This has been tried
but it's not possible to come up with a reliable solution that works
for all netlink protocols.

You should be using a separate socket for notifications.

> - What is missing to use the same "struct nl_sock"

You would have to add a new return code for the valid handler so
it can filter out all notifications and disregard the non existant
NLM_F_MULTI flag. I do not think it's worth the effort though, using
a separate socket has no disadvantages except that it makes
synchronization slightly more difficult.