Re: [PATCH 08/25] IB/uverbs: ufile must be freed only when not used anymore

[Ira Weiny <ira.weiny@intel.com>]

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