From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933251AbdERRwQ (ORCPT ); Thu, 18 May 2017 13:52:16 -0400 Received: from mx2.suse.de ([195.135.220.15]:46303 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751858AbdERRwN (ORCPT ); Thu, 18 May 2017 13:52:13 -0400 Date: Thu, 18 May 2017 19:51:58 +0200 From: Michal Hocko To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , Dan Williams , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCHv5, REBASED 9/9] x86/mm: Allow to have userspace mappings above 47-bits Message-ID: <20170518175158.GF30148@dhcp22.suse.cz> References: <20170515121218.27610-1-kirill.shutemov@linux.intel.com> <20170515121218.27610-10-kirill.shutemov@linux.intel.com> <20170518114359.GB25471@dhcp22.suse.cz> <20170518151952.jzvz6aeelgx7ifmm@node.shutemov.name> <20170518152736.GA18333@dhcp22.suse.cz> <20170518154135.zekuqls6almevrjt@node.shutemov.name> <20170518155003.GB18333@dhcp22.suse.cz> <20170518155914.GC18333@dhcp22.suse.cz> <20170518162255.l55tm5qbmnvvsgba@node.shutemov.name> <20170518171330.GA30148@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170518171330.GA30148@dhcp22.suse.cz> 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 Thu 18-05-17 19:13:30, Michal Hocko wrote: > On Thu 18-05-17 19:22:55, Kirill A. Shutemov wrote: > > On Thu, May 18, 2017 at 05:59:14PM +0200, Michal Hocko wrote: > [...] > > > I basically mean something like the following > > > --- > > > diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c > > > index 74d1587b181d..d6f66ff02d0a 100644 > > > --- a/arch/x86/kernel/sys_x86_64.c > > > +++ b/arch/x86/kernel/sys_x86_64.c > > > @@ -195,7 +195,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, > > > goto bottomup; > > > > > > /* requesting a specific address */ > > > - if (addr) { > > > + if (addr && addr <= DEFAULT_MAP_WINDOW) { > > > addr = PAGE_ALIGN(addr); > > > vma = find_vma(mm, addr); > > > if (TASK_SIZE - len >= addr && > > > @@ -215,7 +215,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, > > > * !in_compat_syscall() check to avoid high addresses for x32. > > > */ > > > if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall()) > > > - info.high_limit += TASK_SIZE_MAX - DEFAULT_MAP_WINDOW; > > > + info.high_limit += min(TASK_SIZE_MAX, address) - DEFAULT_MAP_WINDOW; > > > > > > info.align_mask = 0; > > > info.align_offset = pgoff << PAGE_SHIFT; > > > > You try to stretch the interface too far. With the patch you propose we > > have totally different behaviour wrt hint address if it below and above > > 47-bits: > > > > * <= 47-bits: allocate VM [addr; addr + len - 1], if free; > > unless I am missing something fundamental here this is not how it works. > We just map a different range if the requested one is not free (in > absence of MAP_FIXED). And we do that in top->down direction so this is > already how it works. And you _do_ rely on the same thing when allowing > larger than 47b except you start from the top of the supported address > space. So how exactly is your new behavior any different and more clear? OK, I take that back because I am clearly wrong. We simply always start from top. Sorry about my confusion. Feel free to add Acked-by: Michal Hocko -- Michal Hocko SUSE Labs