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? Could you create a better cover letter for this. What is the use case for all this? What protections are in place for accesses between processes? Why is it not sufficient to share the entire IB context with another process using SCM_RIGHTS? I've been trying to create a reliable method for an admin to identify processes which may have pinned file backed pages (specifically with FS DAX). The best idea I have involves using the struct file of the ucontext to track the file pins through procfs. Jason and I discussed it here: https://lkml.org/lkml/2019/6/7/548 Therefore, sharing to another ucontext _might_ work. But only if the file pin information is properly duplicated to the new ucontext. This complicates (at a minimum) having the generic GUP code handle the tracking of this information... Generically, this whole thread scares me because now we are proposing something even more obscure than just the sharing of a file descriptor to other processes which point to the same IB context. (Or at least that is what I infer from reading the very short cover letter.) But if there is a good use case ... we need to starting thinking about something generic to track these "memory maps" which are not mmaps. Ira
