[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN0PR21MB32641E489F378F0C5B357795CEDCA@MN0PR21MB3264.namprd21.prod.outlook.com>
Date: Fri, 27 Oct 2023 21:35:05 +0000
From: Long Li <longli@...rosoft.com>
To: Ajay Sharma <sharmaajay@...rosoft.com>,
Jason Gunthorpe <jgg@...pe.ca>,
"sharmaajay@...uxonhyperv.com" <sharmaajay@...uxonhyperv.com>
CC: Leon Romanovsky <leon@...nel.org>,
Dexuan Cui <decui@...rosoft.com>, Wei Liu <wei.liu@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [Patch v7 5/5] RDMA/mana_ib: Send event to qp
> Subject: RE: [EXTERNAL] Re: [Patch v7 5/5] RDMA/mana_ib: Send event to qp
>
>
> > -----Original Message-----
> > From: Jason Gunthorpe <jgg@...pe.ca>
> > Sent: Monday, October 23, 2023 11:24 AM
> > To: sharmaajay@...uxonhyperv.com
> > Cc: Long Li <longli@...rosoft.com>; Leon Romanovsky <leon@...nel.org>;
> > Dexuan Cui <decui@...rosoft.com>; Wei Liu <wei.liu@...nel.org>; David S.
> > Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>;
> > Jakub Kicinski <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>;
> > linux- rdma@...r.kernel.org; linux-hyperv@...r.kernel.org;
> > netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Ajay Sharma
> > <sharmaajay@...rosoft.com>
> > Subject: [EXTERNAL] Re: [Patch v7 5/5] RDMA/mana_ib: Send event to qp
> >
> > On Mon, Oct 16, 2023 at 03:12:02PM -0700,
> sharmaajay@...uxonhyperv.com
> > wrote:
> >
> > > diff --git a/drivers/infiniband/hw/mana/qp.c
> > > b/drivers/infiniband/hw/mana/qp.c index ef3275ac92a0..19fae28985c3
> > > 100644
> > > --- a/drivers/infiniband/hw/mana/qp.c
> > > +++ b/drivers/infiniband/hw/mana/qp.c
> > > @@ -210,6 +210,8 @@ static int mana_ib_create_qp_rss(struct ib_qp
> > *ibqp, struct ib_pd *pd,
> > > wq->id = wq_spec.queue_index;
> > > cq->id = cq_spec.queue_index;
> > >
> > > + xa_store(&mib_dev->rq_to_qp_lookup_table, wq->id, qp,
> > GFP_KERNEL);
> > > +
> >
> > A store with no erase?
> >
> > A load with no locking?
> >
> > This can't be right
> >
> > Jason
>
> This wq->id is assigned from the HW and is guaranteed to be unique. May be I
> am not following why do we need a lock here. Can you please explain ?
> Ajay
I think we need to check the return value of xa_store(), and call xa_erase() in mana_ib_destroy_qp().
wq->id is generated by the hardware. If we believe in hardware always behaves in good manner, we don't need a lock.
Thanks,
Long
Powered by blists - more mailing lists