On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote: > On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote: > > Two kernel threads may get the same value for agent.hi_tid, if the > > agents are registered for different ports. As of now, this works, as > > the agent list is per port. > > > > It is however confusing and not future robust. Hence, making it > > atomic. > > > > People sometimes underestimate the performance penalty of atomic ops. > Every atomic op is the equivalent of a spin_lock/spin_unlock pair. This > is why two atomics are worse than taking a spin_lock, doing what you > have to do, and releasing the spin_lock. Is this really what you want > for a "confusing, let's make it robust" issue? But it is on the ib_register_mad_agent() path which is not a performance path.. This actually looks like a genuine bug, why is it described only as 'confusing'? ib_register_mad_agent is callable from userspace, so at least two userspace agents can race and get the same TID's. TIDs need to be globally unique on the entire machine. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
