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;
Date:   Tue, 08 Nov 2022 10:27:51 +0000
From:   Conor Dooley <conor@kernel.org>
To:     linux-riscv@lists.infradead.org, guoren@kernel.org,
        anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com,
        conor.dooley@microchip.com, heiko@sntech.de,
        philipp.tomsich@vrull.eu
CC:     linux-kernel@vger.kernel.org, Guo Ren <guoren@linux.alibaba.com>,
        Guo Ren <guoren@kernel.org>,
        Anup Patel <apatel@ventanamicro.com>,
        Palmer Dabbelt <palmer@rivosinc.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_RESEND=5D_riscv=3A_asid=3A_Fixup_?= =?US-ASCII?Q?stale_TLB_entry_cause_application_crash?=
User-Agent: K-9 Mail for Android
In-Reply-To: <20221108102044.3317793-1-guoren@kernel.org>
References: <20221108102044.3317793-1-guoren@kernel.org>
Message-ID: <D91557B5-7E60-4A29-8669-34FF42454F8C@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 8 November 2022 10:20:44 GMT, guoren@kernel=2Eorg wrote:
>From: Guo Ren <guoren@linux=2Ealibaba=2Ecom>
>
>After use_asid_allocator enabled, the userspace application will
>crash for stale tlb entry=2E Because only using cpumask_clear_cpu without
>local_flush_tlb_all couldn't guarantee CPU's tlb entries fresh=2E Then
>set_mm_asid would cause user space application get a stale value by
>the stale tlb entry, but set_mm_noasid is okay=2E
>
>Here is the symptom of the bug:
>unhandled signal 11 code 0x1 (coredump)
>   0x0000003fd6d22524 <+4>:     auipc   s0,0x70
>   0x0000003fd6d22528 <+8>:     ld      s0,-148(s0) # 0x3fd6d92490
>=3D> 0x0000003fd6d2252c <+12>:    ld      a5,0(s0)
>(gdb) i r s0
>s0          0x8082ed1cc3198b21       0x8082ed1cc3198b21
>(gdb) x/16 0x3fd6d92490
>0x3fd6d92490:   0xd80ac8a8      0x0000003f
>The core dump file shows that the value of register s0 is wrong, but the
>value in memory is right=2E This is because 'ld s0, -148(s0)' use a stale
>mapping entry in TLB and got a wrong value from a stale physical
>address=2E
>
>When task run on CPU0, the task loaded/speculative-loaded the value of
>address(0x3fd6d92490), and the first version of tlb mapping entry was
>PTWed into CPU0's tlb=2E
>When the task switched from CPU0 to CPU1 without local_tlb_flush_all
>(because of asid), the task happened to write a value on address
>(0x3fd6d92490)=2E It caused do_page_fault -> wp_page_copy ->
>ptep_clear_flush -> ptep_get_and_clear & flush_tlb_page=2E
>The flush_tlb_page used mm_cpumask(mm) to determine which CPUs need
>tlb flush, but CPU0 had cleared the CPU0's mm_cpumask in previous switch_=
mm=2E
>So we only flushed the CPU1 tlb, and setted second version mapping
>of the pte=2E When the task switch from CPU1 to CPU0 again, CPU0 still us=
ed a
>stale tlb mapping entry which contained a wrong target physical address=
=2E
>When the task happened to read that value, the bug would be raised=2E
>
>Fixes: 65d4b9c53017 ("RISC-V: Implement ASID allocator")
>Signed-off-by: Guo Ren <guoren@linux=2Ealibaba=2Ecom>
>Signed-off-by: Guo Ren <guoren@kernel=2Eorg>
>Cc: Anup Patel <apatel@ventanamicro=2Ecom>
>Cc: Palmer Dabbelt <palmer@rivosinc=2Ecom>
>---
> arch/riscv/mm/context=2Ec | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/arch/riscv/mm/context=2Ec b/arch/riscv/mm/context=2Ec
>index 7acbfbd14557=2E=2E8ad6c2493e93 100644
>--- a/arch/riscv/mm/context=2Ec
>+++ b/arch/riscv/mm/context=2Ec
>@@ -317,7 +317,9 @@ void switch_mm(struct mm_struct *prev, struct mm_stru=
ct *next,
> 	 */
> 	cpu =3D smp_processor_id();
>=20
>-	cpumask_clear_cpu(cpu, mm_cpumask(prev));
>+	if (!static_branch_unlikely(&use_asid_allocator))
>+		cpumask_clear_cpu(cpu, mm_cpumask(prev));
>+
> 	cpumask_set_cpu(cpu, mm_cpumask(next));
>=20
> 	set_mm(next, cpu);

This is a completely different patch to what you already sent=2E Why have =
you marked it RESEND rather than v2?