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

[Roopa Prabhu]

On 1/31/13 1:09 AM, Thomas Graf wrote:
> 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.
>>

Want to add a note here. If a user had bridges configured and even 
though he did not request for AF_BRIDGE objects with NL_CACHE_AF_ITER, 
AF_BRIDGE link objects can end up in the link cache due to kernel 
AF_BRIDGE async events. Which means, an old app running on a system with 
bridges, could get an AF_BRIDGE object with rtnl_link_get_by_name or 
rtnl_link_get with newer libnl versions (after AF_BRIDGE support).

Things will be fine if the app checks for family and uses the object.
Wondering if this should be a concern otherwise.