[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2807E5FD2F6FDA4886F6618EAC48510E1CBD4369@CRSMSX101.amr.corp.intel.com>
Date: Wed, 28 Oct 2015 04:30:10 +0000
From: "Weiny, Ira" <ira.weiny@...el.com>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
"Wan, Kaike" <kaike.wan@...el.com>
CC: Saurabh Sengar <saurabh.truth@...il.com>,
"dledford@...hat.com" <dledford@...hat.com>,
"Hefty, Sean" <sean.hefty@...el.com>,
"hal.rosenstock@...il.com" <hal.rosenstock@...il.com>,
"yun.wang@...fitbricks.com" <yun.wang@...fitbricks.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
>
> On Tue, Oct 27, 2015 at 06:56:50PM +0000, Wan, Kaike wrote:
>
> > > I do wonder if it is a good idea to call ib_nl_send_msg with a
> > > spinlock held though.. Would be nice to see that go away.
> >
> > We have to hold the lock to protect against a race condition that a
> > quick response will try to free the request from the
> > ib_nl_request_list before we even put it on the list.
>
> Put is on the list first? Use a kref? Doesn't look like a big deal to clean this up.
>
> Jason
Not sure what "Put is on the list first?" means. I think it is valid to build the request,
if success, add to the list, then send it. That would solve the problem you mention
above. Was that what you hand in mind, Jason?
I don't have time to work on this right now, not sure about Kaike. Until we can remove
the spinlock the current proposed patch should be applied in the interim. Sorry for the
noise before.
Reviewed-By: Ira Weiny <ira.weiny@...el.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists