Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: qM0JWs1/SeoLNIDo4H4L8fJPnV2hBAPZGscfJlPzF1X7M+y0XFuf93uxR5sCeV9O4KPdHerTPI
 T2uQD53Hds3w==
IronPort-SDR: lzwrNbDJy/zXwX3C7CwXLxw3KkWOLT7VbR7XhzYmpIoQK7g7gY6AdSSB28DdIOFqbdx1GoqU9d
 qfhd6wAYoAlg==
Date:   Thu, 28 May 2020 14:15:07 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Sean Christopherson <sean.j.christopherson@intel.com>
Cc:     Haitao Huang <haitao.huang@linux.intel.com>,
        Nathaniel McCallum <npmccallum@redhat.com>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        linux-sgx@vger.kernel.org, akpm@linux-foundation.org,
        dave.hansen@intel.com, Neil Horman <nhorman@redhat.com>,
        "Huang, Haitao" <haitao.huang@intel.com>,
        andriy.shevchenko@linux.intel.com, tglx@linutronix.de,
        "Svahn, Kai" <kai.svahn@intel.com>, bp@alien8.de,
        Josh Triplett <josh@joshtriplett.org>, luto@kernel.org,
        kai.huang@intel.com, David Rientjes <rientjes@google.com>,
        "Xing, Cedric" <cedric.xing@intel.com>,
        Patrick Uiterwijk <puiterwijk@redhat.com>
Subject: Re: [PATCH v29 00/20] Intel SGX foundations
Message-ID: <20200528111507.GA1666298@linux.intel.com>
References: <20200421215316.56503-1-jarkko.sakkinen@linux.intel.com>
 <CAOASepPFe_ucuwe7JW_-+VBQ4=+sHqyGXOdA9kUbcYA_9=v0sA@mail.gmail.com>
 <20200506221422.GK3329@linux.intel.com>
 <op.0j8dm0zzwjvjmi@hhuan26-mobl1.amr.corp.intel.com>
 <CAOASepNVckens=wiWpHj291EAo0ndi7GCVHd9j7BPn8rjy7Ykg@mail.gmail.com>
 <20200507193459.GA24519@linux.intel.com>
 <op.0j9qdhziwjvjmi@hhuan26-mobl1.amr.corp.intel.com>
 <20200508002555.GA24964@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200508002555.GA24964@linux.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, May 07, 2020 at 05:25:55PM -0700, Sean Christopherson wrote:
> Ah, fudge.  shmem_zero_setup() triggers shmem_acct_size() and thus
> __vm_enough_memory().  Which I should have rememered because I've stared
> at that code several times when dealing with the enclave's backing store.
> I wasn't seeing the issue because I happened to use MAP_PRIVATE.
> 
> So, bad analysis, good conclusion, i.e. the kernel is still doing the
> right thing, it's just not ideal for userspace.
> 
> 
> Jarkko, we should update the docs and selftest to recommend and use
> 
>   PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS
> 
> or
> 
>   PROT_NONE, MAP_SHARED | MAP_NORESERVE | MAP_ANONYMOUS"
> 
> when carving out ELRANGE, with an explicit comment that all the normal
> rules for mapping memory still apply.

Ugh, had forgotten this.

OK, I guess this comment explains it all:

"
/*
 * shmem_file_setup pre-accounts the whole fixed size of a VM object,
 * for shared memory and for shared anonymous (/dev/zero) mappings
 * (unless MAP_NORESERVE and sysctl_overcommit_memory <= 1),
 * consistent with the pre-accounting of private mappings ...
 */
static inline int shmem_acct_size(unsigned long flags, loff_t size)
"

/Jarkko