RE: [PATCH v1 00/24] Shared PD and MR

Weiny, Ira
2019-08-22T20:10:14Z

> On Thu, Aug 22, 2019 at 09:58:42AM -0700, Ira Weiny wrote:
>
> > Add to your list "how does destruction of a MR in 1 process get
> > communicated to the other?" Does the 2nd process just get failed WR's?
>
> IHMO a object that has been shared can no longer be asynchronously destroyed.
> That is the whole point. A lkey/rkey # alone is inherently unsafe without also
> holding a refcount on the MR.
>
> > I have some of the same concerns as Doug WRT memory sharing. FWIW I'm
> > not sure that what SCM_RIGHTS is doing is safe or correct.
> >
> > For that work I'm really starting to think SCM_RIGHTS transfers should
> > be blocked.
>
> That isn't possible, SCM_RIGHTS is just some special case, fork(), exec(), etc all
> cause the same situation. Any solution that blocks those is a total non-starter.

Right, except in the case of fork(), exec() all of the file system references which may be pinned also get copied. With SCM_RIGHTS they may not... And my concern here is, if I understand this mechanism, it would introduce another avenue where the file pin is shared _without_ the file lease (or with a potentially zombie'ed lease).[1]

[1] https://lkml.org/lkml/2019/8/16/994

>
> > It just seems wrong that Process B gets references to Process A's
> > mm_struct and holds the memory Process A allocated.
>
> Except for ODP, a MR doesn't reference the mm_struct. It references the pages.
> It is not unlike a memfd.

I'm thinking of the owner_mm... It is not like it is holding the entire process address space I know that. But it is holding onto memory which Process A allocated.

Ira

>
> Jason