On Wed, Jan 09, 2019 at 04:42:37PM +0200, Gal Pressman wrote: > On 09-Jan-19 02:05, Jason Gunthorpe wrote: > > > >> This can be solved by freeing the PDs on dealloc_ucontext time which > >> will guarantee that no other process will get the same BAR pages. > > > > Depends on the implementation. > > > > What is coming next is 'shared pd' which will allow the PD HW object > > to be pointed at by multiple different ucontext's. (this is another > > reason why you can't really remove the mmap cookie on first use, as to > > make a correct driver for shared-PD the sharing flow will have to > > re-mmap the BAR pages, presumably.) > > > > The implementation of deferred destroy would need to very carefully > > handle this. > > In case of a shared PD, are the different ucontexts expected to share the same > BAR pages? I'm guessing EFA would need that since the BAR page is linked to the PD. > Sounds like a PD reference count will be needed in order to free it > on last using ucontext dealloc. Something like that is in Shamir's patches > We can also just fail mmaps for pages that are still used by a different > ucontext instead of deferring the PD deallocation. How do you know if they are still used? > Is there a way to notify the driver of munmaps? instead of waiting for > dealloc_ucontext? Yes, but I prefer if drivers don't go back to implementing vma_ops, it is complicated. Jason
