[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170802164001.GF21775@redhat.com>
Date: Wed, 2 Aug 2017 18:40:01 +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 Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote:
> 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
Well this whole issue about which retval, is about a mere detail in
the first place, so I don't think you can discount all other mere
details as irrelevant in the evaluation of a change to solve a mere
detail.
> 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.
The only change would be for userfaultfd non cooperative mode, and
CRIU is the main user of that. So I think it is up to Mike to decide,
I'm fine either ways. I certainly agree ESRCH could be a slightly
better fit, I only wanted to clarify it's not a 100% match either.
Powered by blists - more mailing lists