From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5673 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Reviewing if_nameindex and getifaddrs patch Date: Tue, 29 Jul 2014 10:34:54 -0400 Message-ID: <20140729143454.GH1674@brightrain.aerifal.cx> References: <20140728004906.GA14406@brightrain.aerifal.cx> <20140728111327.658049f2@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406644516 12557 80.91.229.3 (29 Jul 2014 14:35:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Jul 2014 14:35:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5678-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 29 16:35:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XC8Ue-0008Gr-1f for gllmg-musl@plane.gmane.org; Tue, 29 Jul 2014 16:35:08 +0200 Original-Received: (qmail 9383 invoked by uid 550); 29 Jul 2014 14:35:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9375 invoked from network); 29 Jul 2014 14:35:07 -0000 Content-Disposition: inline In-Reply-To: <20140728111327.658049f2@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5673 Archived-At: 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