From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752020AbdBUKy3 (ORCPT ); Tue, 21 Feb 2017 05:54:29 -0500 Received: from foss.arm.com ([217.140.101.70]:58492 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbdBUKyS (ORCPT ); Tue, 21 Feb 2017 05:54:18 -0500 Date: Tue, 21 Feb 2017 10:54:12 +0000 From: Catalin Marinas To: "Kirill A. Shutemov" Cc: Linus Torvalds , 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: <20170221105412.GB31018@e104818-lin.cambridge.arm.com> References: <20170217141328.164563-1-kirill.shutemov@linux.intel.com> <20170217141328.164563-34-kirill.shutemov@linux.intel.com> <20170221103401.GA31018@e104818-lin.cambridge.arm.com> <20170221104736.GA13174@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170221104736.GA13174@node.shutemov.name> 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 Tue, Feb 21, 2017 at 01:47:36PM +0300, Kirill A. Shutemov wrote: > On Tue, Feb 21, 2017 at 10:34:02AM +0000, Catalin Marinas wrote: > > 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). > > I've limited STACK_TOP to 47-bit in my implementation of Linus' proposal: > > http://lkml.kernel.org/r/20170220131515.GA9502@node.shutemov.name Ah, sorry for the noise then (still catching up with this thread; at some point we'll need to add 52-bit VA support to arm64, though with 4 levels only). -- Catalin