RE: [PATCH v7 rdma-next 2/7] RDMA/core: Create mmap database and cookie helper functions

[Michal Kalderon <mkalderon@marvell.com>]

> From: Gal Pressman <galpress@amazon.com>
> Sent: Sunday, August 25, 2019 1:40 PM
> 
> On 25/08/2019 11:36, Michal Kalderon wrote:
> >>> diff --git a/drivers/infiniband/core/rdma_core.c
> >>> b/drivers/infiniband/core/rdma_core.c
> >>> index ccf4d069c25c..7166741834c8 100644
> >>> --- a/drivers/infiniband/core/rdma_core.c
> >>> +++ b/drivers/infiniband/core/rdma_core.c
> >>> @@ -817,6 +817,7 @@ static void ufile_destroy_ucontext(struct
> >> ib_uverbs_file *ufile,
> >>>  	rdma_restrack_del(&ucontext->res);
> >>>
> >>>  	ib_dev->ops.dealloc_ucontext(ucontext);
> >>> +	rdma_user_mmap_entries_remove_free(ucontext);
> >>
> >> Why did you switch the order again?
> > To enable drivers to remove the entries from the mmap_xa otherwise
> > entires_remove_free Will run into a mmap_xa that is not empty. I should
> have mentioned this in the cover letter.
> 
> I don't understand.
> Do you expect drivers to explicitly drain the mmap xarray during
> dealloc_ucontext? I didn't see that in the EFA patch.
> 
> I still think the xarray should be cleared prior to calling the driver's
> dealloc_ucontext.

Drivers don't need to explicitly drain the xarray, but in qedr the driver inserts
An entry during alloc_ucontext, and therefore should remove the entry on dealloc
Ucontext. We want to reacc the remove_free function with no entries. When going
Over this code again I think I can completely remove the function and just add a 
WARN_ON on the dealloc_ucontext function. Having an entry at this point means there
Is a leak.