On 4/18/2012 6:04 AM, David Miller wrote:
It is the only major instance that I don't personally have plans for a
dst_neigh_lookup() conversion. I can't do some of those
transformations to dst_neigh_lookup() in net/ipv4 and net/ipv6 until
the others are out of the way.
understood, thanks for clarifying this out.
Just for the sake of example, does the atm code free from the races you mention
re ipoib? I see that it does stick its own object on the neighbour through the
priv pointer but wasn't sure if it helps in that respect without further
RCU-ing things.
I haven't audited ATM for races of any kind, and I have no plans to do so,
sorry. Please, I did fully audit and analyze the IPoIB case, so please use one
of the approaches suggsted.
okay, so please let me phrase that differently, would it be correct to
say that if we stick to the 1st approach of still somehow associating
the ipoib_neigh with the neighbour - no matter through what means we do
that - RCU-ing is must here. Specifically, the neighbour->priv
mechanism wouldn't get us a way from adding that protection? or maybe
it could make our life easier if we turn to use it?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
