> Subject: Re: [PATCH v1 00/24] Shared PD and MR > > 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? Dave Chinner is suggesting the close will hang. Exec with CLOEXEC would probably not because the RDMA close would release the pin allowing the close of the data file to finish... At least as far as my testing has shown. > > It completely breaks the unix model to tie something to a process not to a > FD. But that is just it. Dave is advocating that the FD's must get transferred. It has nothing to do with a process. I'm somewhat confused at this point because in this thread I was advocating that the RDMA context FD is what needs to get "shared" between the processes. Is that what you are advocating as well? Does this patch set do that? > > > > 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. But those pages aren't necessarily mapped in Process B. and if they are mapped in Process A then you are sending data to Process A not "B"... That is one twisted way to look at it anyway... Ira
