Re: Reviewing if_nameindex and getifaddrs patch

[Rich Felker <dalias@libc.org>]

On Mon, Jul 28, 2014 at 11:13:27AM +0300, Timo Teras wrote:
> > I really don't understand the 'hash' logic for getifaddrs yet, but the
> > function seems to work. Some general description of what data the
> > callback receives and what it's doing with it could be helpful for
> > reviewing this part of the patch.
> 
> The rtnetlink enumerate does two netlink 'dumps'. One of 'link' type
> that dumps the physical interfaces, and one of 'addr' type that lists
> all network addresses.
> 
> The 'link' dump is used to get the PF_PACKET ifaddrs with mac
> addresses, as well as to get the ifindex<->ifname mappings and the
> logical flags of each physical interface (SIOCGIFFLAGS equivalent).
> These put into the hash based on ifindex.
> 
> The 'addr' dump then does the ipv4/ipv6 address (easy to extend if we
> need to support something new in future). These lookup the physical
> 'link' info using ifindex. This is needed to fill ifa_flags with valid
> data. It is also used to lookup the interface in non-ipv4 case. (In
> ipv4 case it seems that kernel always sends IFA_LABEL containing the
> real or aliased interface name. Though this probably might change if
> the alias interface system is removed at some point.)

I see. One random thought I had, since you're merging information from
two sources: is there any atomicity guarantee here, or is it possible
that interfaces have changed between the link and addr dumps? I don't
think issues like this should block getting it committed since it's at
least better than what we have now with respect to atomicity, but I
noticed the unused NLM_F_ATOMIC flag and wonder if that could be used
to perform both requests atomically (if they're not already atomic).

Aside from that I'm going to apply the patch again, look at the
resulting code, and make sure I don't see anything else that needs to
be fixed. If it looks ok, I'll go ahead and apply it.

Rich