From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA056C433EF for ; Fri, 15 Apr 2022 22:09:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2252F6B0072; Fri, 15 Apr 2022 18:09:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D4D36B0073; Fri, 15 Apr 2022 18:09:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C5276B0074; Fri, 15 Apr 2022 18:09:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id F24D76B0072 for ; Fri, 15 Apr 2022 18:09:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A1208119E for ; Fri, 15 Apr 2022 22:09:32 +0000 (UTC) X-FDA: 79360505784.19.B3C1BCC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 08A46140005 for ; Fri, 15 Apr 2022 22:09:31 +0000 (UTC) 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 35DBD621AA; Fri, 15 Apr 2022 22:09:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52D9FC385A5; Fri, 15 Apr 2022 22:09:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1650060570; bh=uUTQqgUrEzM7Si1aiQakKXkiczJd/bLPM5S7/8UuewM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=v1978BaeFognAVHsSsO/IbUq5gZ2MfdtX3pU/XfWl2EDOtBmtFQ6U+QxtPEPewUqy t8q0ImX7X34MWexGSi8QR/FRCIG0iO6Gg1TIx7Sr10hjd0BuyBxZPfCgdzHbgK1OpC 360VyOfe0eoYqVGzTn++ivmyJmcy7oHU68eCY6qI= Date: Fri, 15 Apr 2022 15:09:29 -0700 From: Andrew Morton To: Christophe Leroy Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Steve Capper , Will Deacon , Catalin Marinas , stable@vger.kernel.org Subject: Re: [PATCH v10] mm, hugetlbfs: Allow for "high" userspace addresses Message-Id: <20220415150929.a62cbad83c22d6304560f626@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 08A46140005 X-Stat-Signature: sukkbesisnuzpjg7cjt6nefgogowwkeh Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=v1978Bae; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1650060571-566869 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 15 Apr 2022 16:45:13 +0200 Christophe Leroy wrote: > 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. > > >From Catalin (ARM64): > 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. I'm struggling to understand the need for a -stable backport from the above text. Could we please get a simple statement of the end-user visible effects of the shortcoming? Target audience is -stable tree maintainers, and people who we've never heard of who will be wondering whether they should add this to their organization's older kernel. > fs/hugetlbfs/inode.c | 9 +++++---- > include/linux/sched/mm.h | 8 ++++++++ > mm/mmap.c | 8 -------- > 3 files changed, 13 insertions(+), 12 deletions(-) I'm a bit surprised that this has reached version 10! Was it really that tricky?