Hi Doug, > -----Original Message----- > From: Doug Ledford <dledford@xxxxxxxxxx> > Sent: Friday, September 21, 2018 11:06 AM > To: Parav Pandit <parav@xxxxxxxxxxxx>; Leon Romanovsky > <leon@xxxxxxxxxx>; Jason Gunthorpe <jgg@xxxxxxxxxxxx> > Cc: Leon Romanovsky <leonro@xxxxxxxxxxxx>; RDMA mailing list <linux- > rdma@xxxxxxxxxxxxxxx>; Daniel Jurgens <danielj@xxxxxxxxxxxx> > Subject: Re: [PATCH rdma-next v1 3/3] RDMA/cma: Introduce and use > cma_ib_acquire_dev() > > On Thu, 2018-09-20 at 17:25 +0000, Parav Pandit wrote: > > so maybe I can spin two unrelated patches before/after this series whose > pseudo code is below? > > Yes please, and make them part of this series. > I looked again. The problem I described is not true. I remember now when referred the code again. rdma_destroy_id depends on their underlying module (ib_cm) for synchronization to not run in clear the cma_dev while request handler is in progress. So if the cma_ib_req_handler() is executing on ib_cm_id, respective listen_id cannot be destroyed, because ib_destroy_cm_id() is creating the barrier. I believe this is fragile design, but I think it's safe to rely on this for this patch series on current rdmacm and ib_cm being this way? (new patch is not adding any functional degradation). With that I request to review if rest of the code changes looks fine to proceed. I forgot and had to revisit this non intuitive code 2nd time, so at minimum I like to spin the patch to include such tricky code comments in rdma_destroy_id(). > -- > Doug Ledford <dledford@xxxxxxxxxx> > GPG KeyID: B826A3330E572FDD > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
