Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1995958pxb; Wed, 30 Mar 2022 14:14:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6nYouiQRVFgJgyA4/9CYcTjEcdcZsdymEFiqAUHKZXEbjnsT0IfQ9o9n67H8cbuzgPqLf X-Received: by 2002:a17:907:3e99:b0:6db:6c1c:d9d9 with SMTP id hs25-20020a1709073e9900b006db6c1cd9d9mr1677415ejc.688.1648674859809; Wed, 30 Mar 2022 14:14:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648674859; cv=none; d=google.com; s=arc-20160816; b=bWok3gelA1jY6TE0c1iQIkOY22TfH2G5S1qT3UlyD4W/M10uR0V3KJQXX4wTkqDfhS ogjMjsEqDQn62NZw8m047eLOgZxWl2EppL0pkzQGRZ8YNuNuKWIwFCZCGNnKKMQEMOn9 czVm+uBQKMgZ33ZwK7Gs1USyU/bcPlJk2Ytq4FnCGycRYsTI4CYPq9/CGmg9kAC23TnR qOC6hRER+ypJiOjOAjO6BfwVJVkKwCknedkczbVUQIdATR/oCjI278GHDcp3vCe4oizB O2zBmuVzPOnedD/FmnJtgPdEky5ZuswJIQLgjK4UuM4NwBSqMXPog6LUBuW9oQp1eGpR Js/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ghHV0zTkwP6Ex+XA+hsxUv5AW9dRVc+dHJyFR6M/CLc=; b=G/yNSCzgq4ISOzNOTD7t+Kh3QcvUlRhyg6Ko5faqsssdfw//z5NdYPWHaLtabFKyTc hjoBvSNBycXgxueDWDwNLVDfOlUHR9/8BvbWaFxR3q6ABpP3IkgK/Wdnuk8VZoS+jn/5 vy0CT4ePbSHM+SkiZiCCsM7eAV6N9xVHr6/5AleAY+VzgrUsDKakjhxofSrBHrKr8N50 MWFpjT6DmQwgUaxF3gY4HLD1mmeQz6jyqUaEQE+aIzZJfm37vwMp2AHIOg5gRTJi8qG3 72TnnlfPg06IPGd2yasLRcvlbTTKw65tlZ9Lwju+kt5dyLR0s4lzgBjc7rnj9WIulPe5 8fKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=MsUahD2s; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i2-20020a170906444200b006df76385bd9si20491701ejp.121.2022.03.30.14.13.45; Wed, 30 Mar 2022 14:14:19 -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=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=MsUahD2s; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243988AbiC3Hy3 (ORCPT + 99 others); Wed, 30 Mar 2022 03:54:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233214AbiC3HyV (ORCPT ); Wed, 30 Mar 2022 03:54:21 -0400 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07936201B2 for ; Wed, 30 Mar 2022 00:52:35 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id i4so9176194wrb.5 for ; Wed, 30 Mar 2022 00:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ghHV0zTkwP6Ex+XA+hsxUv5AW9dRVc+dHJyFR6M/CLc=; b=MsUahD2sxOxVEYlWECPO8kAt9VWOJpDQrtlreD3+bqkhw6vqNTK7bkZs6OOon1C6qX GpbFyKlDNhAqt8EU07FcYzmKQCKWU8+dLr7J2vWKm07zQpKdZWWdJsUKMjmFwO7z3kgO ljbjsPLVmaqLtD2DX1UFh9cXZZ3nXDr8NqkLOpvAbNesPZlas4vzAyG4MqMRk8iTnZEt Cp9dEq/u/8ZXj0C9UnfxccSpro0iLZKhgkpdWEzBo/MGugutUi4WcBZkJHaTGc0yW17O 7v8SPsemPb5HX/KxdDLzvzO3EMoTD8wyuMik9aADy6vTeF4jsF0AwzoZO1OmKEIxd0Ur L4Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ghHV0zTkwP6Ex+XA+hsxUv5AW9dRVc+dHJyFR6M/CLc=; b=vU6UjEGwhHplZjNUXET9HJ0iD2usHgRdTUIMTWacS2ft4ozQCs/GYN78zMPDbSQVVd nYGrzm+sge8x7wnjUy26uZ4ZAKihtRK2Xw2z6kgu61kh9njmeUiVqzTS22xLgO5E2Dxr GWEffgtyhi9iFhigqgtFNVlbGKeQqaU60b06QwO0BFaokKycZho4cR6Qf3xkzi1tBkBB oj1cUh81TNl7l76ZZE9hg6YnTObfbbOcPMKXAj1gntjm345nWHRO6uETmdxyphHH7jLt tfesUCqeGuyqPbiLSZCkzZtpFGZcWyUSxaIGfqV5xm8YCILpc3EuiYi7JZVFPjvZ0iHE cumA== X-Gm-Message-State: AOAM5310ZiDoufJbKsk66xjW+MiLyamIzWQX3rs2mAI44kY3g0pGWQax 3+QfGs9bgsoFiXRNMq6puUAsCvqvA1tt7gRdSKnWTA== X-Received: by 2002:adf:db86:0:b0:205:bccf:8cbf with SMTP id u6-20020adfdb86000000b00205bccf8cbfmr19955087wri.346.1648626753267; Wed, 30 Mar 2022 00:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20220330073347.3898802-1-alistair.francis@opensource.wdc.com> In-Reply-To: <20220330073347.3898802-1-alistair.francis@opensource.wdc.com> From: Anup Patel Date: Wed, 30 Mar 2022 13:22:21 +0530 Message-ID: Subject: Re: [PATCH] riscv: Ensure only ASIDLEN is used for sfence.vma To: Alistair Francis Cc: linux-riscv , Palmer Dabbelt , Paul Walmsley , Albert Ou , "linux-kernel@vger.kernel.org List" , Atish Patra , Guo Ren , Alistair Francis Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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 On Wed, Mar 30, 2022 at 1:04 PM Alistair Francis wrote: > > From: Alistair Francis > > When we set the value of context.id using __new_context() we set both > the asid and the current_version with this return statement in > __new_context(): > > return asid | ver; > > This means that when local_flush_tlb_all_asid() is called with the asid > specified from context.id we can write the incorrect value. > > We get away with this as hardware ignores the extra bits, as the RISC-V > specification states: > > "bits SXLEN-1:ASIDMAX of the value held in rs2 are reserved for future > standard use. Until their use is defined by a standard extension, they > should be zeroed by software and ignored by current implementations." > > but it is still a bug and worth addressing as we are incorrectly setting > extra bits. > > This patch uses asid_mask when calling sfence.vma to ensure the asid is > always the correct len (ASIDLEN). This is similar to what we do in > arch/riscv/mm/context.c. > > Signed-off-by: Alistair Francis Instead of fixing various local_flush_tlb_xyz() functions, I suggest fixing the __sbi_tlb_flush_range() in tlbflush.c which passes incorrect ASID. (Refer line 45, "unsigned long asid = atomic_long_read(&mm->context.id);") Also, please add the "Fixes: " tag. Regards, Anup > --- > arch/riscv/mm/context.c | 2 +- > arch/riscv/mm/tlbflush.c | 4 ++-- > include/linux/mm_types.h | 2 ++ > 3 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/mm/context.c b/arch/riscv/mm/context.c > index 7acbfbd14557..4329fe54176b 100644 > --- a/arch/riscv/mm/context.c > +++ b/arch/riscv/mm/context.c > @@ -22,7 +22,7 @@ DEFINE_STATIC_KEY_FALSE(use_asid_allocator); > > static unsigned long asid_bits; > static unsigned long num_asids; > -static unsigned long asid_mask; > +unsigned long asid_mask; > > static atomic_long_t current_version; > > diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c > index 37ed760d007c..4469615aa07f 100644 > --- a/arch/riscv/mm/tlbflush.c > +++ b/arch/riscv/mm/tlbflush.c > @@ -10,7 +10,7 @@ static inline void local_flush_tlb_all_asid(unsigned long asid) > { > __asm__ __volatile__ ("sfence.vma x0, %0" > : > - : "r" (asid) > + : "r" (asid & asid_mask) > : "memory"); > } > > @@ -19,7 +19,7 @@ static inline void local_flush_tlb_page_asid(unsigned long addr, > { > __asm__ __volatile__ ("sfence.vma %0, %1" > : > - : "r" (addr), "r" (asid) > + : "r" (addr), "r" (asid & asid_mask) > : "memory"); > } > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 8834e38c06a4..5fa7cc0af853 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -666,6 +666,8 @@ struct mm_struct { > > extern struct mm_struct init_mm; > > +extern unsigned long asid_mask; > + > /* Pointer magic because the dynamic array size confuses some compilers. */ > static inline void mm_init_cpumask(struct mm_struct *mm) > { > -- > 2.35.1 >