On Thu, Aug 22, 2019 at 08:10:09PM +0000, Weiny, Ira wrote: > > 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. And what happens one one child of the fork closes the reference, or exec with CLOEXEC causes it to no inherent? It completely breaks the unix model to tie something to a process not to a FD. > > 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. It only hold the mm for some statistics accounting, it is really just holding pages outside the mm. Jason
