From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone
Date: Mon, 31 Jul 2017 16:36:23 +0300 [thread overview]
Message-ID: <20170731133622.GC28632@rapoport-lnx> (raw)
In-Reply-To: <20170731122204.GB4878@dhcp22.suse.cz>
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...
Well, I don't remember why I used ENOSPC in userfault_copy at the first
place, but if we are to keep it userfaultfd_zeropage should return the same
error...
> > Cc: stable@vger.kernel.org
> > Fixes: 96333187ab162 ("userfaultfd_copy: return -ENOSPC in case mm has gone")
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > ---
> >
> > Unfortunately, I've overlooked userfaultfd_zeropage when I updated
> > userfaultd_copy :(
> >
> > fs/userfaultfd.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index cadcd12a3d35..2d8c2d848668 100644
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -1643,6 +1643,8 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx,
> > ret = mfill_zeropage(ctx->mm, uffdio_zeropage.range.start,
> > uffdio_zeropage.range.len);
> > mmput(ctx->mm);
> > + } else {
> > + return -ENOSPC;
> > }
> > if (unlikely(put_user(ret, &user_uffdio_zeropage->zeropage)))
> > return -EFAULT;
> > --
> > 2.7.4
> >
> > --
> > 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone
Date: Mon, 31 Jul 2017 16:36:23 +0300 [thread overview]
Message-ID: <20170731133622.GC28632@rapoport-lnx> (raw)
In-Reply-To: <20170731122204.GB4878@dhcp22.suse.cz>
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...
Well, I don't remember why I used ENOSPC in userfault_copy at the first
place, but if we are to keep it userfaultfd_zeropage should return the same
error...
> > Cc: stable@vger.kernel.org
> > Fixes: 96333187ab162 ("userfaultfd_copy: return -ENOSPC in case mm has gone")
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > ---
> >
> > Unfortunately, I've overlooked userfaultfd_zeropage when I updated
> > userfaultd_copy :(
> >
> > fs/userfaultfd.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> > index cadcd12a3d35..2d8c2d848668 100644
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -1643,6 +1643,8 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx,
> > ret = mfill_zeropage(ctx->mm, uffdio_zeropage.range.start,
> > uffdio_zeropage.range.len);
> > mmput(ctx->mm);
> > + } else {
> > + return -ENOSPC;
> > }
> > if (unlikely(put_user(ret, &user_uffdio_zeropage->zeropage)))
> > return -EFAULT;
> > --
> > 2.7.4
> >
> > --
> > 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2017-07-31 13:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-27 6:26 [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone Mike Rapoport
2017-07-27 6:26 ` Mike Rapoport
2017-07-31 12:22 ` Michal Hocko
2017-07-31 12:22 ` Michal Hocko
2017-07-31 13:32 ` Andrea Arcangeli
2017-07-31 13:32 ` Andrea Arcangeli
2017-07-31 13:45 ` Michal Hocko
2017-07-31 13:45 ` Michal Hocko
2017-08-02 12:34 ` Mike Rapoport
2017-08-02 12:34 ` Mike Rapoport
2017-08-02 13:21 ` Dr. David Alan Gilbert
2017-08-02 13:21 ` Dr. David Alan Gilbert
2017-08-02 15:55 ` Andrea Arcangeli
2017-08-02 15:55 ` Andrea Arcangeli
2017-08-02 16:22 ` Michal Hocko
2017-08-02 16:22 ` Michal Hocko
2017-08-02 16:40 ` Andrea Arcangeli
2017-08-02 16:40 ` Andrea Arcangeli
2017-08-03 17:24 ` Mike Rapoport
2017-08-03 17:24 ` Mike Rapoport
2017-08-03 21:25 ` Andrea Arcangeli
2017-08-03 21:25 ` Andrea Arcangeli
2017-07-31 13:36 ` Mike Rapoport [this message]
2017-07-31 13:36 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170731133622.GC28632@rapoport-lnx \
--to=rppt@linux.vnet.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dgilbert@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xemul@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.