On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote: > On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote: > > On Thu 27-07-17 09:26:59, Mike Rapoport wrote: > > > In the non-cooperative userfaultfd case, the process exit may race with > > > outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC > > > instead of -EINVAL when mm is already gone will allow uffd monitor to > > > distinguish this case from other error conditions. > > > > Normally we tend to return ESRCH in such case. ENOSPC sounds rather > > confusing... > > This is in sync and consistent with the retval for UFFDIO_COPY upstream: > > if (mmget_not_zero(ctx->mm)) { > ret = mcopy_atomic(ctx->mm, uffdio_copy.dst, uffdio_copy.src, > uffdio_copy.len); > mmput(ctx->mm); > } else { > return -ENOSPC; > } > > If you preferred ESRCH I certainly wouldn't have been against, but we > should have discussed it before it was upstream. All it matters is > it's documented in the great manpage that was written for it as quoted > below. OK, I wasn't aware of this. > +.TP > +.B ENOENT > +(Since Linux 4.11) > +The faulting process has changed > +its virtual memory layout simultaneously with outstanding > +.I UFFDIO_COPY > +operation. > +.TP > +.B ENOSPC > +(Since Linux 4.11) > +The faulting process has exited at the time of > +.I UFFDIO_COPY > +operation. > > To change it now, we would need to involve manpage and other code > changes. Well, ESRCH is more appropriate so I would rather change it sooner than later. But if we are going to risk user space breakage then this is not worth the risk. I expected there are very few users of this API currently so maybe it won't be a big disaster? Anyway, at least this is documented so I will leave the decision to you. -- Michal Hocko SUSE Labs