linux-kernel - Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170803172442.GA1026@rapoport-lnx>
Date:   Thu, 3 Aug 2017 20:24:43 +0300
From:   Mike Rapoport <rppt@...ux.vnet.ibm.com>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Michal Hocko <mhocko@...nel.org>,
        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:40:01PM +0200, Andrea Arcangeli wrote:
> 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.

I'm Ok with updating the code and the man page as long as Michal takes the
blame if anything but CRIU breaks :)

Now, seriously, I believe there are not many users of non-cooperative uffd
if at all and it is very unlikely anybody has it in production.

I'll send a patch with s/ENOSPC/ESRCH in the next few days.

-- 
Sincerely yours,
Mike.