[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180420153451.GF30433@ziepe.ca>
Date: Fri, 20 Apr 2018 09:34:51 -0600
From: Jason Gunthorpe <jgg@...pe.ca>
To: Doug Ledford <dledford@...hat.com>
Cc: Håkon Bugge <Haakon.Bugge@...cle.com>,
Don Hiatt <don.hiatt@...el.com>,
Dasaratharaman Chandramouli
<dasaratharaman.chandramouli@...el.com>,
Ira Weiny <ira.weiny@...el.com>,
Sean Hefty <sean.hefty@...el.com>, linux-rdma@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] IB/core: Make ib_mad_client_id atomic
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
Powered by blists - more mailing lists