From: Michal Hocko <mhocko@kernel.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
"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: Wed, 2 Aug 2017 18:22:49 +0200 [thread overview]
Message-ID: <20170802162248.GA3476@dhcp22.suse.cz> (raw)
In-Reply-To: <20170802155522.GB21775@redhat.com>
On Wed 02-08-17 17:55:22, Andrea Arcangeli wrote:
> On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote:
> > 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?
>
> The manpage would need updates, from v4.11 to v4.13 -ENOSPC, from v4.1
> -ESRCH and I don't see the benefit and it just looks confusion for
> nothing, but if somebody feel strongly about it and does the work (and
> risks to take the blame if something breaks...) I wouldn't be against
> it, it won't make much of a difference anyway.
>
> The reason I don't see any benefit in code readability is that I don't
> see ESRCH as an obviously better retval, because if you grep for ESRCH
> you'll see it's a failure to find a process with a certain pid, it is
> an obvious retval when you're dealing with processes and pids, but we
> never search pids and in fact the pid and the process may be already
> gone but we still won't return ESRCH. UFFDIO_COPY never takes a pid as
> parameter anywhere so why to return ESRCH?
ESRCH refers to "no such process". Strictly speaking userfaultfd code is
about a mm which is gone but that is a mere detail. In fact the owner of
the mm is gone as well. You might not refer to the process by its pid
but you are surely refer to a process via its address space. That's why
I think this error code is more appropriate.
But as I've said, this might be really risky to change. My impression
was that userfaultfd is not widely used yet and those can be fixed
easily but if that is not the case then we have to live with the current
ENOSPC.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-02 16:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-27 6:26 Mike Rapoport
2017-07-31 12:22 ` Michal Hocko
2017-07-31 13:32 ` Andrea Arcangeli
2017-07-31 13:45 ` Michal Hocko
2017-08-02 12:34 ` Mike Rapoport
2017-08-02 13:21 ` Dr. David Alan Gilbert
2017-08-02 15:55 ` Andrea Arcangeli
2017-08-02 16:22 ` Michal Hocko [this message]
2017-08-02 16:40 ` Andrea Arcangeli
2017-08-03 17:24 ` Mike Rapoport
2017-08-03 21:25 ` Andrea Arcangeli
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=20170802162248.GA3476@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--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=rppt@linux.vnet.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox