RE: [RESEND RFC PATCH 0/5] Remote mapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Fri, Sep 04, 2020 at 01:24:43PM +0000, Mircea CIRJALIU - MELIU wrote:
> > > On Fri, Sep 04, 2020 at 02:31:11PM +0300, Adalbert Lazăr wrote:
> > > > VMAs obtained by mmap()ing memory access fds mirror the contents
> > > > of the remote process address space within the specified range.
> > > > Pages are installed in the current process page tables at fault
> > > > time and removed by the mmu_interval_notifier invalidate callbck.
> > > > No further memory
> > > management is involved.
> > > > On attempts to access a hole, or if a mapping was removed by
> > > > PIDFD_MEM_UNMAP, or if the remote process address space was
> reaped
> > > by
> > > > OOM, the remote mapping fault handler returns VM_FAULT_SIGBUS.
> > >
> > > I still think anything along these lines needs to meet the XPMEM use
> > > cases as well, we have to have more general solutions for such MM
> > > stuff:
> > >
> > > https://gitlab.com/hjelmn/xpmem
> > >
> > > However, I think this fundamentally falls into some of the same bad
> > > direction as xpmem.
> > >
> > > I would much rather see this design copy & clone the VMA's than try
> > > to mirror the PTEs inside the VMAs from the remote into a single
> > > giant VMA and somehow split/mirror the VMA ops.
> >
> > This design was made specifically for virtual machine introspection,
> > where we care more about the contents of the address space, rather
> > than the remote VMAs and their vmops. (Right now only anon pages can
> > be mapped, but I guess we can extend to pagecache pages as well.) I
> > just used what seemed to be the common denominator to all page-related
> operations: range invalidation.
> > This looks like a general solution.
> 
> The point is that a VMA is how the MM connects its parts together, cloning
> the content of a VMA without the rest of the VMA meta-data is just going to
> be very fragile in the long run..
> 
> Especially if the VMA is presented as a normal VMA with working struct
> pages/etc, not a pfn map.
>
> > IMO cloning a VMA in an address space that has a completely different
> > layout will present its own set of caveats: What happens if the VMA
> resizes/splits?
> > Can you replay all the remote VMA vmops on the clone VMA?
> 
> The mirror would have to reclone the source VMA every time the source
> VMA changes.
> 
> > > This is just too weird and fragile to be maintaible over a long term.
> > >
> > > For instance, one of the major bugs in things like xpmem was that
> > > they are incompatible with get_user_pages(), largely because of this
> issue.
> >
> > We support get_user_pages(), that's how we integrate with KVM.
> 
> This seems really sketchy, get_user_pages is sensitive to the VMA, what
> happens when VMA flags are different/etc?

A debugger shouldn't complain if a portion of the debuggee is read-only,
just overwrite the data.

> Jason




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux