[PATCH] link cache: remove AF_UNSPEC check in rtnl_get_link and rtnl_get_link_by_name

[Thomas Graf]

On 01/28/13 at 07:46am, roopa at cumulusnetworks.com wrote:
> From: roopa <roopa at cumulusnetworks.com>
> 
> This patch reverts back the AF_UNSPEC check introduced by AF_BRIDGE
> changes at http://lists.infradead.org/pipermail/libnl/2012-November/000796.html
> 
> After the addition of AF_BRIDGE support, link cache can now contain objects of
> type AF_BRIDGE. To make sure existing api's did not return AF_BRIDGE objects
> and surprise existing callers, I introduced the check for AF_UNSPEC.
> 
> But from what Andy Wang reported, rtnl_link_get_by_name returns the first
> link object with matching ifindex and that could have not only been AF_UNSPEC
> but also of family AF_INET6. And his app always got an AF_INET6 object prior
> to the patch that introduced the AF_UNSPEC check.
> 
> I could just add AF_INET6 family check along with AF_UNSPEC in the apis and that
> should work well.
> 
> But thinking about it some more, removing the AF_UNSPEC change seems to be safer at
> this point. That way this api will retain its semantics and return the first object
> with matching ifindex. It could be of any supported family. The user will know if the
> cache contains bridge objects, because they are available only with the cache flag
> NL_CACHE_AF_ITER. Besides, if new users want to search for a specific object,
> nl_cache_find is a better option.
> 
> Reported-by: Andy Wang <Andy.Wang at watchguard.com>
> Signed-off-by: Roopa Prabhu <roopa at cumulusnetworks.com>

I agree, patch applied.
Thanks Roopa and thanks Andy!