[PATCH v2 2/2] Add master support to rtnl_neigh for AF_BRIDGE objects

[Roopa Prabhu]

On 11/15/12 6:44 AM, Thomas Graf wrote:
> On 11/14/12 at 11:33am, roopa at cumulusnetworks.com wrote:
>> +	/*
>> +	 * Get the bridge index for AF_BRIDGE family entries
>> +	 */
>> +	if (neigh->n_family == AF_BRIDGE) {
>> +		struct nl_cache *lcache = nl_cache_mngt_require("route/link");
>> +		if (lcache ) {
>> +			struct rtnl_link *link = rtnl_link_get(lcache,
>> +							neigh->n_ifindex);
>> +			if (link) {
>> +				neigh->n_master = link->l_master;
>> +				rtnl_link_put(link);
>> +				neigh->ce_mask |= NEIGH_ATTR_MASTER;
>> +			}
>> +		}
>> +	}
>> +
>
> So what if no link cache has been made available? n_master will always
> be 0 and we can't uniquely identify AF_BRIDGE cache entries, right?

yes, the thought there was things will still continue to work with just 
lladdr and family because lladdrs are usually unique in an environment.

I understand the concern, and thats why I had called this out explicitly 
in a separate patch. I have looked at adding bridge index in the kernel 
msg, and since the bridge driver uses the neighbour attributes, adding 
the master index there seemed out of place.


Can this be documented ?. or made explicit some other way..maybe a check 
during cache_manager add for AF_BRIDGE. ?

thanks for the review.

>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl