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 D24E3CD4F32 for ; Fri, 22 Sep 2023 08:36:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C1E36B029E; Fri, 22 Sep 2023 04:36:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64B136B029F; Fri, 22 Sep 2023 04:36:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5141A6B02A0; Fri, 22 Sep 2023 04:36:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3E4866B029E for ; Fri, 22 Sep 2023 04:36:19 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1443340E93 for ; Fri, 22 Sep 2023 08:36:19 +0000 (UTC) X-FDA: 81263576478.06.F0DDC90 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id A7EAE40021 for ; Fri, 22 Sep 2023 08:36:16 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695371776; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5XWPDJ0gxGYJwFk15JtO9BVDAWITGYKqaFod5Fs+8x4=; b=kIzKieWPSzRNUdPdVHpgQFhyeqAfaBp7rUPUKS4BLgw+PT6KW2tE/mrp17yLgumxlVQHVC dvzxchGU5Odqa0ql3UME987McZQh6EY/d8MoWmRgpYfWy7FvxLtaMRnHBm4BXM5JTep5Kb nbIk1kU7qGwk+CI3RaGSVyyalUUghgc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695371776; a=rsa-sha256; cv=none; b=RKXuNbvGLqJQ1v9I4Kr7/d2SgfsgNX+iL6uix01SY0M95HEj233s/P/hY9Tt26n0SKoU6Z O39Z07h3XPhzke8HduLHT+WifyD9cKgo7ZS8FL+AgBJRRyhQ7+jUlDG22rOp2DrJZ7NZde GjdsGxh/Z71/ten3U8enjZOWK7hZmEQ= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8B69FDA7; Fri, 22 Sep 2023 01:36:52 -0700 (PDT) Received: from [10.57.65.11] (unknown [10.57.65.11]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2F7F03F67D; Fri, 22 Sep 2023 01:36:09 -0700 (PDT) Message-ID: Date: Fri, 22 Sep 2023 09:36:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/8] riscv: hugetlb: Convert set_huge_pte_at() to take vma Content-Language: en-GB To: Alexandre Ghiti , Catalin Marinas , Will Deacon , "James E.J. Bottomley" , Helge Deller , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Gerald Schaefer , "David S. Miller" , Arnd Bergmann , Mike Kravetz , Muchun Song , SeongJae Park , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Anshuman Khandual , Peter Xu , Axel Rasmussen , Qi Zheng Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org References: <20230921162007.1630149-1-ryan.roberts@arm.com> <20230921162007.1630149-4-ryan.roberts@arm.com> <7bbceed4-c5f6-42d4-5d94-060032b73385@ghiti.fr> From: Ryan Roberts In-Reply-To: <7bbceed4-c5f6-42d4-5d94-060032b73385@ghiti.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: bdj8617mz3sybzq9w3tfj8kxkar7arj3 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A7EAE40021 X-HE-Tag: 1695371776-121772 X-HE-Meta: U2FsdGVkX18yzID9dumHIJhtwFfWVToETU9jqKN+UMyVKf2zxlm1ZhLeoH8uWrgoPNAONj0T70gprnTtA8ClsTPiw3BeatZzvlStW7pfjA8iVbhBaBx6v8ymFKD83Qrc8AspZfvmzdYvwPm2Ny8Uw4EpxYC6P+f+LXBst0rfGKZnYHmPSqD0ybtJRFjDE3ecGA0GgsblZrS2Y3H7Ne4Hc2Ku8jTypUnSEKDIZ5my4pZ8FMhSrZIoEthgT9hidgSDSpiz3DYmYFA/lrZeN3uTGKFSPHKrsYIYVpk5zAHia1Cl4ZXn9nwpHxK75r+/WQtaj3d/nWfytBcoU3p7WCr4hmur6cthhrESX4V2AW8tdhJoVo0GjpAFl8/0JhFbcL1+Rve7LnQFlqRM2nMnMpLQ++YVnOdCZM3vXcfNfNqD822b81dAQUsJujFCh3VHdFM3BtHIe6RGET+7ciPjIpmTSAwHR1lp/OkYEtTNQW/8eejQ5NkAOPUKJDJ+q0zyVjEFWk984w3e/M/9020kUmxKKGncuvOsmqwJAKWHldsHt/o/9akHaLvpAAOnzJd+bDW+Pe2bhrSayG//JMBmDa0EgEkXrlHstPpO87Jdx1LTaHOxdiSBzSIDVRbDmokM8ckMTH7Fhi3SIcMdm287Q8E4W9X0Nm3PpY5EYXePzu6wYq+/6pLikZonyEQ3LNN1r8iLO+HqVHTba+b3+Itro9oWHW66iBk9rl26KxqntHbR3gOQNXpir8prIz3kVz6bd08k7MZ/3ERImlgEgOK/9l7znKVpcsM792WpmSQFP4USB/M3DNJVMffWHvclWSQCgHbX+tCYOwcuQ5C36PK+YskTIBYDvmxed6baCAorbwd74iqoz4VjxmNa4cOPipLYwNrHQxSrFniXzKPwdQm4edEolF04mwBGx5FtU2q6mLpZQ7PRoYkjNNyED9uWebzniHsuCSj9Ko1s9s0e9Ytkv/y VIUDekYV YLmctjIXu6gAZtBQV8xFeBvoSkb2pmbhZ2yHwarF7Xry7pzOrvW85NYBACpov2mJsLmFTGrkhiywPLVMxEGda0gZZC+DG0hwCiIIKohMAwdFqT2Q763WbGE9Y1r4yhjA46zz9WajCs4k1NrnJ2+w2odgQVGfwL3p/YrIhps1J8v67ljp8Ak9cejGt3AtgSNsJa91fj5LkjZinE7aDDDkWjClWHRYW/cMcg0uq0K5XKe1sc0ymsjbQ4uoNZCWzL4JrJs4RsTcmoCKY8kPwqOoBh2NsvO1ZeQ4lA37ApMQ0syHe8h+V4BD9TDJyjnMD3FsgqwDd 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 22/09/2023 08:54, Alexandre Ghiti wrote: > Hi Ryan, > > On 21/09/2023 18:20, Ryan Roberts wrote: >> In order to fix a bug, arm64 needs access to the vma inside it's >> implementation of set_huge_pte_at(). Provide for this by converting the >> mm parameter to be a vma. Any implementations that require the mm can >> access it via vma->vm_mm. >> >> This commit makes the required riscv modifications. Separate commits >> update the other arches and core code, before the actual bug is fixed in >> arm64. >> >> No behavioral changes intended. >> >> Signed-off-by: Ryan Roberts >> --- >>   arch/riscv/include/asm/hugetlb.h | 2 +- >>   arch/riscv/mm/hugetlbpage.c      | 3 ++- >>   2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/arch/riscv/include/asm/hugetlb.h b/arch/riscv/include/asm/hugetlb.h >> index 34e24f078cc1..be1ac8582bc2 100644 >> --- a/arch/riscv/include/asm/hugetlb.h >> +++ b/arch/riscv/include/asm/hugetlb.h >> @@ -17,7 +17,7 @@ void huge_pte_clear(struct mm_struct *mm, unsigned long addr, >>               pte_t *ptep, unsigned long sz); >>     #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT >> -void set_huge_pte_at(struct mm_struct *mm, >> +void set_huge_pte_at(struct vm_area_struct *vma, >>                unsigned long addr, pte_t *ptep, pte_t pte); >>     #define __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR >> diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c >> index 96225a8533ad..7cdbf0960772 100644 >> --- a/arch/riscv/mm/hugetlbpage.c >> +++ b/arch/riscv/mm/hugetlbpage.c >> @@ -177,11 +177,12 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int >> shift, vm_flags_t flags) >>       return entry; >>   } >>   -void set_huge_pte_at(struct mm_struct *mm, >> +void set_huge_pte_at(struct vm_area_struct *vma, >>                unsigned long addr, >>                pte_t *ptep, >>                pte_t pte) >>   { >> +    struct mm_struct *mm = vma->vm_mm; >>       int i, pte_num; >>         if (!pte_napot(pte)) { > > > You can add: > > Reviewed-by: Alexandre Ghiti Thanks! > > I realize that we may have the same issue with our contig pte implementation > (called napot in riscv) as we don't handle swap/migration entries at all. So I > guess we need something similar, and I'll implement it (unless you want to do it > of course, but I guess it's easier for me to test). Yes -I'll leave you to do the riscv part. > One (maybe stupid) question > though: wouldn't it be possible to extract the contig pte size from the value of > ptep instead of using a vma? Not for arm64: We support contpmd, pmd and contpte entries as backing for the logical huge pte, depending on size. So without the size, we can't distinguish between a coincidentally-aligned pmd entry vs a contpmd entry (which is just a fixed size block of pmd entries). Discussion with Christophe on the powerpc patch triggered some thinking; There is theoretical problem with my current approach because there is one call site in the core code that calls set_huge_pte_at(&init_mm). I've changed that to: struct vm_area_struct vma = TLB_FLUSH_VMA(&init_mm, 0); set_huge_pte_at(&vma); knowing that this will never actually get called for arm64 because we return PAGE_SIZE for arch_vmap_pte_range_map_size() and all other arches just take the mm and ignore the rest of the vma. So it's safe, but fragile. But it looks like riscv overrides arch_vmap_pte_range_map_size() and therefore the call will be made there. And if riscv also needs to determine the size from the vma, then bang. So I'm going to rework it to continue to pass the mm in, but also add a size parameter. Then it's totally safe. Will post a v2 later today. Thanks, Ryan > > Thanks, > > Alex >