From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934937AbdBQUCT (ORCPT ); Fri, 17 Feb 2017 15:02:19 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:33672 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932467AbdBQUCP (ORCPT ); Fri, 17 Feb 2017 15:02:15 -0500 MIME-Version: 1.0 In-Reply-To: <20170217141328.164563-34-kirill.shutemov@linux.intel.com> References: <20170217141328.164563-1-kirill.shutemov@linux.intel.com> <20170217141328.164563-34-kirill.shutemov@linux.intel.com> From: Linus Torvalds Date: Fri, 17 Feb 2017 12:02:13 -0800 X-Google-Sender-Auth: 15xZnq2efn8zIJdRNdu-hmTqPYk Message-ID: Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR To: "Kirill A. Shutemov" Cc: Andrew Morton , "the arch/x86 maintainers" , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , "linux-arch@vger.kernel.org" , linux-mm , Linux Kernel Mailing List , Catalin Marinas , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 17, 2017 at 6:13 AM, Kirill A. Shutemov wrote: > This patch introduces two new prctl(2) handles to manage maximum virtual > address available to userspace to map. So this is my least favorite patch of the whole series, for a couple of reasons: (a) adding new code, and mixing it with the mindless TASK_SIZE -> get_max_addr() conversion. (b) what's the point of that whole TASK_SIZE vs get_max_addr() thing? When use one, when the other? so I think this patch needs a lot more thought and/or explanation. Honestly, (a) is a no-brainer, and can be fixed by just splitting the patch up. But I think (b) is more fundamental. In particular, I think that get_max_addr() thing is badly defined. When should you use TASK_SIZE, when should you use TASK_SIZE_MAX, and when should you use get_max_addr()? I don't find that clear at all, and I think that needs to be a whole lot more explicit and documented. I also get he feeling that the whole thing is unnecessary. I'm wondering if we should just instead say that the whole 47 vs 56-bit virtual address is _purely_ about "get_unmapped_area()", and nothing else. IOW, I'm wondering if we can't just say that - if the processor and kernel support 56-bit user address space, then you can *always* use the whole space - but by default, get_unmapped_area() will only return mappings that fit in the 47 bit address space. So if you use MAP_FIXED and give an address in the high range, it will just always work, and the MM will always consider the task size to be the full address space. But for the common case where a process does no use MAP_FIXED, the kernel will never give a high address by default, and you have to do the process control thing to say "I want those high addresses". Hmm? In other words, I'd like to at least start out trying to keep the differences between the 47-bit and 56-bit models as simple and minimal as possible. Not make such a big deal out of it. We already have "arch_get_unmapped_area()" that controls the whole "what will non-MAP_FIXED mmap allocations return", so I'd hope that the above kind of semantics could be done without *any* actual TASK_SIZE changes _anywhere_ in the VM code. Comments? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR Date: Fri, 17 Feb 2017 12:02:13 -0800 Message-ID: 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=UTF-8 Return-path: In-Reply-To: <20170217141328.164563-34-kirill.shutemov@linux.intel.com> Sender: owner-linux-mm@kvack.org To: "Kirill A. Shutemov" Cc: Andrew Morton , the arch/x86 maintainers , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , "linux-arch@vger.kernel.org" , linux-mm , Linux Kernel Mailing List , Catalin Marinas , Linux API List-Id: linux-api@vger.kernel.org On Fri, Feb 17, 2017 at 6:13 AM, Kirill A. Shutemov wrote: > This patch introduces two new prctl(2) handles to manage maximum virtual > address available to userspace to map. So this is my least favorite patch of the whole series, for a couple of reasons: (a) adding new code, and mixing it with the mindless TASK_SIZE -> get_max_addr() conversion. (b) what's the point of that whole TASK_SIZE vs get_max_addr() thing? When use one, when the other? so I think this patch needs a lot more thought and/or explanation. Honestly, (a) is a no-brainer, and can be fixed by just splitting the patch up. But I think (b) is more fundamental. In particular, I think that get_max_addr() thing is badly defined. When should you use TASK_SIZE, when should you use TASK_SIZE_MAX, and when should you use get_max_addr()? I don't find that clear at all, and I think that needs to be a whole lot more explicit and documented. I also get he feeling that the whole thing is unnecessary. I'm wondering if we should just instead say that the whole 47 vs 56-bit virtual address is _purely_ about "get_unmapped_area()", and nothing else. IOW, I'm wondering if we can't just say that - if the processor and kernel support 56-bit user address space, then you can *always* use the whole space - but by default, get_unmapped_area() will only return mappings that fit in the 47 bit address space. So if you use MAP_FIXED and give an address in the high range, it will just always work, and the MM will always consider the task size to be the full address space. But for the common case where a process does no use MAP_FIXED, the kernel will never give a high address by default, and you have to do the process control thing to say "I want those high addresses". Hmm? In other words, I'd like to at least start out trying to keep the differences between the 47-bit and 56-bit models as simple and minimal as possible. Not make such a big deal out of it. We already have "arch_get_unmapped_area()" that controls the whole "what will non-MAP_FIXED mmap allocations return", so I'd hope that the above kind of semantics could be done without *any* actual TASK_SIZE changes _anywhere_ in the VM code. Comments? Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org