> 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
