From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751922AbdBUKeQ (ORCPT ); Tue, 21 Feb 2017 05:34:16 -0500 Received: from foss.arm.com ([217.140.101.70]:58070 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbdBUKeI (ORCPT ); Tue, 21 Feb 2017 05:34:08 -0500 Date: Tue, 21 Feb 2017 10:34:02 +0000 From: Catalin Marinas To: Linus Torvalds Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Andrew Morton , "linux-arch@vger.kernel.org" , Linux API , the arch/x86 maintainers , Andi Kleen , "Kirill A. Shutemov" , Arnd Bergmann , Dave Hansen , Linux Kernel Mailing List , "H. Peter Anvin" , linux-mm Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR Message-ID: <20170221103401.GA31018@e104818-lin.cambridge.arm.com> References: <20170217141328.164563-1-kirill.shutemov@linux.intel.com> <20170217141328.164563-34-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 17, 2017 at 03:21:27PM -0800, Linus Torvalds wrote: > On Feb 17, 2017 3:02 PM, "Andy Lutomirski" wrote: > > What I'm trying to say is: if we're going to do the route of 48-bit > > limit unless a specific mmap call requests otherwise, can we at least > > have an interface that doesn't suck? > > No, I'm not suggesting specific mmap calls at all. I'm suggesting the complete > opposite: not having some magical "max address" at all in the VM layer. Keep > all the existing TASK_SIZE defines as-is, and just make those be the new 56-bit > limit. > > But to then not make most processes use it, just make the default x86 > arch_get_free_area() return an address limited to the old 47-bit limit. So > effectively all legacy programs work exactly the same way they always did. arch_get_unmapped_area() changes would not cover STACK_TOP which is currently defined as TASK_SIZE (on both x86 and arm64). I don't think it matters much (normally such upper bits tricks are done on heap objects) but you may find some weird user program that passes pointers to the stack around and expects bits 48-63 to be masked out. If that's a real issue, we could also limit STACK_TOP to 47-bit (48-bit on arm64). -- Catalin