[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170731133247.GK29716@redhat.com>
Date: Mon, 31 Jul 2017 15:32:47 +0200
From: Andrea Arcangeli <aarcange@...hat.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
linux-mm <linux-mm@...ck.org>,
lkml <linux-kernel@...r.kernel.org>, stable@...r.kernel.org
Subject: Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone
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.
+.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.
Thanks,
Andrea
Powered by blists - more mailing lists