On 4/18/2012 9:15 AM, David Miller wrote:
I would need to have to go back to the original thread and reread and
reabsorb the full analysis I did back then to answer this, and I
really don't have time to do that right now. You're going to have to
figure out how to fix this race properly on your own or with someone
else's help.
Sure, I didn't ask you to redo the analysis for the ipoib use case, its
well understood.
I just wanted to see if you can spare few sentences regarding the
neighbour priv mechanism you added in the below sequence, all are your
patches from July 2011 which I think means they were introduced in 3.1.0
Specifically, is there an existing RCU neighbour related framework/call
that a driver which uses neighbour_priv(n) and probably also the
neigh_construct/destroy ndo callbacks, can use to make sure that
modifying the private area isn't racy with readers of that area?
BTW I see that in commit 596b9b68ef118f7409afbc78487263e08ef96261 you
changed IPoIB to set
dev->neigh_priv_len to be sizeof(ipoib_neigh), so you've started a
possible porting here..
Or.
I took a look on the below series and also commit
32092ecf0644e91070f9eff4f6e1edda8f90aecc
"atm: clip: Use device neigh support on top of "arp_tbl" " which made
atm to use the neigh_construct call.
commit da6a8fa0275e2178c44a875374cae80d057538d1
neigh: Add device constructor/destructor capability.
If the neigh entry has device private state, it will need
constructor/destructor ops.
commit 869759b9e4160fb8a8d25bc3b4ce3b658523aebb
atm: clip: Convert over to neighbour_priv()
commit 76cc714ed5fe6ed90aad5c52ff3030f1f4e22a48
neigh: Do not set tbl->entry_size in ipv4/ipv6 neigh tables.
Let the core self-size the neigh entry based upon the key length.
commit 596b9b68ef118f7409afbc78487263e08ef96261
neigh: Add infrastructure for allocating device neigh privates.
netdev->neigh_priv_len records the private area length.
This will trigger for neigh_table objects which set tbl->entry_size
to zero, and the first instances of this will be forthcoming.
commit 5b8b0060cbd6332ae5d1fa0bec0e8e211248d0e7
neigh: Get rid of neigh_table->kmem_cachep
We are going to alloc for device specific private areas for
neighbour entries, and in order to do that we have to move
away from the fixed allocation size enforced by using
neigh_table->kmem_cachep
As a nice side effect we can now use kfree_rcu().
Signed-off-by: David S. Miller <[email protected]>
commit 1026fec8739663621d64216ba939c23bc1d089b7
neigh: Create mechanism for generic neigh private areas.
The implementation private sits right after the primary_key memory.
--
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
