Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3651651ioa; Tue, 26 Apr 2022 07:34:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfpF4wcAg/fysESO+xK+if0FMQ0qHJOfmc0ghQKSh5sY6xMvj84RAcQ9MS5NPaV1xFrxnN X-Received: by 2002:a63:89c3:0:b0:3ab:238f:134d with SMTP id v186-20020a6389c3000000b003ab238f134dmr10921791pgd.387.1650983653582; Tue, 26 Apr 2022 07:34:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650983653; cv=none; d=google.com; s=arc-20160816; b=GO+B26erMp533OcZUBgF5UgD/uQujHyj7UL+6s+o8phX9POqH89DTJY0ETmQRG11jZ 597fLOQasiiyu22ceWsxM0v9Scvgv2xiUd/l4jvVfpK4uIjwoJIxIRsoYVEu9zi+LHaY u62Qsh09LvXO1x1rYjGrOMvWXn8NhcMWWGgrNZ4+l12JylhAQ0rrx4buWQnGlrw20I1n cm2O7K98nNYyc0lyw+07FdZwHH3NUCyN3zTAS9haJf6PiaKhJhIW4y35DWw4+eATdg35 BemDLN9AU1DehZ5HBsuukD4Xgfc1WnOcgMqormpFnDVj1r6UQlxPFAXr5moyS5t2CbVu +X9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=QGC/o2j1uPMdNaRaAVmvuFeBBZBXBTRFXQDjkvrBZys=; b=duuvDEkDSDEGin2Mzn7/DKreiJz9pTZr27TiaiNTnzz6wAYlvipPrXru/ruQIHiAbZ hJILuA1AtJqhosvYJnE7t4aihQo0umlMJoLKmhtc9rjAWtTAPFR1UuZil7kETYrqIJPh t7NKrfcFtFEBw0TRZiWzgqbnglCN1jEMMgMk0Ik4DVrAuY7D51caAahvtJVJdVhrFlbc 7CezZ9oc8aVCHxY35DOay9im6dyLBpEjnzz1KPbawCSpaERJdKOPRQ+qtcfSc9G544H/ Oysv1AWqViBT422ok381tPfxbzyCuOU3YFRNLspxod7HeI/R7sPYSoMyLzrqNCt7N5Sn Sw7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=d8M6YVKd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bv19-20020a17090af19300b001cbbd85faa9si2227231pjb.20.2022.04.26.07.33.54; Tue, 26 Apr 2022 07:34:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=d8M6YVKd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347185AbiDZJTj (ORCPT + 99 others); Tue, 26 Apr 2022 05:19:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345986AbiDZIoc (ORCPT ); Tue, 26 Apr 2022 04:44:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF7A015DD70; Tue, 26 Apr 2022 01:33:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 45B7F618CD; Tue, 26 Apr 2022 08:33:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5739DC385AC; Tue, 26 Apr 2022 08:33:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650962038; bh=NkjpnB1JMCM3Gxx3RxT3ohoq76DY1JvBF7Ui9nKMvxI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d8M6YVKdS1xKRx4xzW/Yz3beraUpMCvmwv/vRGFdTUaJxVxIQaQcnT47X1QqfXsT8 Wp0PoUf3bHPL78Db+WkC09C7j+Sq9Ah3qdPj/MX2jc/AzDkjutamwxssAWnmY3kaHy TvMT2glxb5t3Uz2W6YNYiFNEQ4LbY5bY2v8OCrxg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christophe Leroy , Catalin Marinas , Steve Capper , Will Deacon , Andrew Morton , Linus Torvalds Subject: [PATCH 5.10 52/86] mm, hugetlb: allow for "high" userspace addresses Date: Tue, 26 Apr 2022 10:21:20 +0200 Message-Id: <20220426081742.705539014@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220426081741.202366502@linuxfoundation.org> References: <20220426081741.202366502@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christophe Leroy commit 5f24d5a579d1eace79d505b148808a850b417d4c upstream. This is a fix for commit f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") for hugetlb. This patch adds support for "high" userspace addresses that are optionally supported on the system and have to be requested via a hint mechanism ("high" addr parameter to mmap). Architectures such as powerpc and x86 achieve this by making changes to their architectural versions of hugetlb_get_unmapped_area() function. However, arm64 uses the generic version of that function. So take into account arch_get_mmap_base() and arch_get_mmap_end() in hugetlb_get_unmapped_area(). To allow that, move those two macros out of mm/mmap.c into include/linux/sched/mm.h If these macros are not defined in architectural code then they default to (TASK_SIZE) and (base) so should not introduce any behavioural changes to architectures that do not define them. For the time being, only ARM64 is affected by this change. Catalin (ARM64) said "We should have fixed hugetlb_get_unmapped_area() as well when we added support for 52-bit VA. The reason for commit f6795053dac8 was to prevent normal mmap() from returning addresses above 48-bit by default as some user-space had hard assumptions about this. It's a slight ABI change if you do this for hugetlb_get_unmapped_area() but I doubt anyone would notice. It's more likely that the current behaviour would cause issues, so I'd rather have them consistent. Basically when arm64 gained support for 52-bit addresses we did not want user-space calling mmap() to suddenly get such high addresses, otherwise we could have inadvertently broken some programs (similar behaviour to x86 here). Hence we added commit f6795053dac8. But we missed hugetlbfs which could still get such high mmap() addresses. So in theory that's a potential regression that should have bee addressed at the same time as commit f6795053dac8 (and before arm64 enabled 52-bit addresses)" Link: https://lkml.kernel.org/r/ab847b6edb197bffdfe189e70fb4ac76bfe79e0d.1650033747.git.christophe.leroy@csgroup.eu Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") Signed-off-by: Christophe Leroy Reviewed-by: Catalin Marinas Cc: Steve Capper Cc: Will Deacon Cc: [5.0.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- fs/hugetlbfs/inode.c | 9 +++++---- include/linux/sched/mm.h | 8 ++++++++ mm/mmap.c | 8 -------- 3 files changed, 13 insertions(+), 12 deletions(-) --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -206,7 +206,7 @@ hugetlb_get_unmapped_area_bottomup(struc info.flags = 0; info.length = len; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; return vm_unmapped_area(&info); @@ -222,7 +222,7 @@ hugetlb_get_unmapped_area_topdown(struct info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = max(PAGE_SIZE, mmap_min_addr); - info.high_limit = current->mm->mmap_base; + info.high_limit = arch_get_mmap_base(addr, current->mm->mmap_base); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; addr = vm_unmapped_area(&info); @@ -237,7 +237,7 @@ hugetlb_get_unmapped_area_topdown(struct VM_BUG_ON(addr != -ENOMEM); info.flags = 0; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr); addr = vm_unmapped_area(&info); } @@ -251,6 +251,7 @@ hugetlb_get_unmapped_area(struct file *f struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct hstate *h = hstate_file(file); + const unsigned long mmap_end = arch_get_mmap_end(addr); if (len & ~huge_page_mask(h)) return -EINVAL; @@ -266,7 +267,7 @@ hugetlb_get_unmapped_area(struct file *f if (addr) { addr = ALIGN(addr, huge_page_size(h)); vma = find_vma(mm, addr); - if (TASK_SIZE - len >= addr && + if (mmap_end - len >= addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -106,6 +106,14 @@ static inline void mm_update_next_owner( #endif /* CONFIG_MEMCG */ #ifdef CONFIG_MMU +#ifndef arch_get_mmap_end +#define arch_get_mmap_end(addr) (TASK_SIZE) +#endif + +#ifndef arch_get_mmap_base +#define arch_get_mmap_base(addr, base) (base) +#endif + extern void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack); extern unsigned long --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2140,14 +2140,6 @@ unsigned long vm_unmapped_area(struct vm return addr; } -#ifndef arch_get_mmap_end -#define arch_get_mmap_end(addr) (TASK_SIZE) -#endif - -#ifndef arch_get_mmap_base -#define arch_get_mmap_base(addr, base) (base) -#endif - /* Get an address range which is currently unmapped. * For shmat() with addr=0. *