From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) by kanga.kvack.org (Postfix) with ESMTP id 7764B6B05D3 for ; Wed, 2 Aug 2017 09:21:50 -0400 (EDT) Received: by mail-qt0-f199.google.com with SMTP id u19so20947604qtc.14 for ; Wed, 02 Aug 2017 06:21:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id 35si12632441qkp.473.2017.08.02.06.21.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:21:49 -0700 (PDT) Date: Wed, 2 Aug 2017 14:21:44 +0100 From: "Dr. David Alan Gilbert" Subject: Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone Message-ID: <20170802132143.GB2077@work-vm> References: <1501136819-21857-1-git-send-email-rppt@linux.vnet.ibm.com> <20170731122204.GB4878@dhcp22.suse.cz> <20170731133247.GK29716@redhat.com> <20170731134507.GC4829@dhcp22.suse.cz> <20170802123440.GD17905@rapoport-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170802123440.GD17905@rapoport-lnx> Sender: owner-linux-mm@kvack.org List-ID: To: Mike Rapoport Cc: Michal Hocko , Andrea Arcangeli , Andrew Morton , Pavel Emelyanov , linux-mm , lkml , stable@vger.kernel.org * Mike Rapoport (rppt@linux.vnet.ibm.com) wrote: > 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? QEMU doesn't care about the errno value, it just reports it. Dave > > 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@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Don't email: email@kvack.org > > > > -- > Sincerely yours, > Mike. > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org