On Mon, Jul 31, 2017 at 03:45:08PM +0200, Michal Hocko wrote: > 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? I surely can take care of CRIU, but I don't know if QEMU or certain database application that uses userfaultfd rely on this API, not mentioning there maybe other unknown users. Andrea, what do you think? > Anyway, at least this is documented so I will leave the decision to you. > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a> > -- Sincerely yours, Mike.