From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199])
	by kanga.kvack.org (Postfix) with ESMTP id 942966B0003
	for <linux-mm@kvack.org>; Mon, 21 May 2018 20:22:43 -0400 (EDT)
Received: by mail-pf0-f199.google.com with SMTP id d20-v6so10075787pfn.16
        for <linux-mm@kvack.org>; Mon, 21 May 2018 17:22:43 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org. [2607:7c80:54:e::133])
        by mx.google.com with ESMTPS id v66-v6si11994889pgv.344.2018.05.21.17.22.42
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
        Mon, 21 May 2018 17:22:42 -0700 (PDT)
Date: Mon, 21 May 2018 17:22:39 -0700
From: Matthew Wilcox <willy@infradead.org>
Subject: Re: Why do we let munmap fail?
Message-ID: <20180522002239.GA4860@bombadil.infradead.org>
References: <aacd607f-4a0d-2b0a-d8d9-b57c686d24fc@intel.com>
 <CAKOZuetDX905PeLt5cs7e_maSeKHrP0DgM1Kr3vvOb-+n=a7Gw@mail.gmail.com>
 <e6bdfa05-fa80-41d1-7b1d-51cf7e4ac9a1@intel.com>
 <CAKOZuev=Pa6FkvxTPbeA1CcYG+oF2JM+JVL5ELHLZ--7wyr++g@mail.gmail.com>
 <20eeca79-0813-a921-8b86-4c2a0c98a1a1@intel.com>
 <CAKOZuesoh7svdmdNY9md3N+vWGurigDLZ5_xDjwgU=uYdKkwqg@mail.gmail.com>
 <2e7fb27e-90b4-38d2-8ae1-d575d62c5332@intel.com>
 <CAKOZueu8ckN1b-cYOxPhL5f7Bdq+LLRP20NK3x7Vtw79oUT3pg@mail.gmail.com>
 <20c9acc2-fbaf-f02d-19d7-2498f875e4c0@intel.com>
 <CAKOZuesScfm_5=2FYurY3ojdhQtcwPWY+=hayJ5cG7pQU1LP9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKOZuesScfm_5=2FYurY3ojdhQtcwPWY+=hayJ5cG7pQU1LP9g@mail.gmail.com>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Daniel Colascione <dancol@google.com>
Cc: dave.hansen@intel.com, linux-mm@kvack.org, Tim Murray <timmurray@google.com>, Minchan Kim <minchan@kernel.org>

On Mon, May 21, 2018 at 05:00:47PM -0700, Daniel Colascione wrote:
> On Mon, May 21, 2018 at 4:32 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > I think there's still a potential dead-end here.  "Deallocation" does
> > not always free resources.
> 
> Sure, but the general principle applies: reserve resources when you *can*
> fail so that you don't fail where you can't fail.

Umm.  OK.  But you want an mmap of 4TB to succeed, right?  That implies
preallocating one billion * sizeof(*vma).  That's, what, dozens of
gigabytes right there?

I'm sympathetic to wanting to keep both vma-merging and
unmap-anything-i-mapped working, but your proposal isn't going to fix it.

You need to handle the attacker writing a program which mmaps 46 bits
of address space and then munmaps alternate pages.  That program needs
to be detected and stopped.