On Thu, Jul 18, 2019 at 11:45:52PM +0300, Yuval Shaia wrote: > On Thu, Jul 18, 2019 at 09:17:47AM -0300, Jason Gunthorpe wrote: > > On Thu, Jul 18, 2019 at 12:36:37AM +0300, Yuval Shaia wrote: > > > On Wed, Jul 17, 2019 at 01:45:05PM -0700, Matthew Wilcox wrote: > > > > On Wed, Jul 17, 2019 at 11:31:12PM +0300, Yuval Shaia wrote: > > > > > On Wed, Jul 17, 2019 at 04:33:13PM -0300, Jason Gunthorpe wrote: > > > > > > Like I said, drivers that require the creating ucontext as part of the > > > > > > PD and MR cannot support sharing. > > > > > > > > > > Even if we can make sure the process that creates the MR stays alive until > > > > > all reference to this MR completes? > > > > > > > > The kernel can't rely on userspace to do that. > > > > > > ok, how about this: we know that for MR to be shared the memory behinds it > > > should also be shared. > > > > > > In this case, i know it sounds horrifying but do we care that the process > > > that originally created this MR exits? i.e. how about just before the > > > process leaves this world we will find some other ucontext to hold these > > > memory mappings that driver holds? > > > Or how about moving this mapping from ucontext pointed by ib_mr directly to > > > ib_mr? > > > > What are you worrying about? My point is we don't need to *anything* > > if the driver objects for PD and MR don't rely on the ucontext. This > > appears to be the normal case. > > but we saw that mlx4 (and i think also 5) do use the ucontext, i think to > undo umem_get stuff. It is unnecessary, remove it. > > MRs already work fine if they outlive the creating process. > > You mean if we leave the creating process alive? No, let it die, it is fine Jason
