Patch "riscv: Fix IPIs usage in kfence_protect_page()" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    riscv: Fix IPIs usage in kfence_protect_page()

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     riscv-fix-ipis-usage-in-kfence_protect_page.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 89e3d877fe251e0610c885b362c0db27494ad3b8
Author: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
Date:   Mon Dec 9 08:41:25 2024 +0100

    riscv: Fix IPIs usage in kfence_protect_page()
    
    [ Upstream commit b3431a8bb336cece8adc452437befa7d4534b2fd ]
    
    flush_tlb_kernel_range() may use IPIs to flush the TLBs of all the
    cores, which triggers the following warning when the irqs are disabled:
    
    [    3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520
    [    3.456647] Modules linked in:
    [    3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1
    [    3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS
    [    3.457633] epc : smp_call_function_many_cond+0x452/0x520
    [    3.457736]  ra : on_each_cpu_cond_mask+0x1e/0x30
    [    3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50
    [    3.457824]  gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f
    [    3.457859]  t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10
    [    3.457920]  s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001
    [    3.457953]  a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000
    [    3.458006]  a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000
    [    3.458042]  s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0
    [    3.458076]  s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001
    [    3.458109]  s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001
    [    3.458141]  s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0
    [    3.458172]  t5 : 0000000000000000 t6 : ff200000000236d0
    [    3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003
    [    3.458373] [<ffffffff800b669a>] smp_call_function_many_cond+0x452/0x520
    [    3.458593] [<ffffffff800b67c2>] on_each_cpu_cond_mask+0x1e/0x30
    [    3.458625] [<ffffffff8000e4ca>] __flush_tlb_range+0x118/0x1ca
    [    3.458656] [<ffffffff8000e6b2>] flush_tlb_kernel_range+0x1e/0x26
    [    3.458683] [<ffffffff801ea56a>] kfence_protect+0xc0/0xce
    [    3.458717] [<ffffffff801e9456>] kfence_guarded_free+0xc6/0x1c0
    [    3.458742] [<ffffffff801e9d6c>] __kfence_free+0x62/0xc6
    [    3.458764] [<ffffffff801c57d8>] kfree+0x106/0x32c
    [    3.458786] [<ffffffff80588cf2>] detach_buf_split+0x188/0x1a8
    [    3.458816] [<ffffffff8058708c>] virtqueue_get_buf_ctx+0xb6/0x1f6
    [    3.458839] [<ffffffff805871da>] virtqueue_get_buf+0xe/0x16
    [    3.458880] [<ffffffff80613d6a>] virtblk_done+0x5c/0xe2
    [    3.458908] [<ffffffff8058766e>] vring_interrupt+0x6a/0x74
    [    3.458930] [<ffffffff800747d8>] __handle_irq_event_percpu+0x7c/0xe2
    [    3.458956] [<ffffffff800748f0>] handle_irq_event+0x3c/0x86
    [    3.458978] [<ffffffff800786cc>] handle_simple_irq+0x9e/0xbe
    [    3.459004] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a
    [    3.459027] [<ffffffff804bf87c>] imsic_handle_irq+0xba/0x120
    [    3.459056] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a
    [    3.459080] [<ffffffff804bdb76>] riscv_intc_aia_irq+0x24/0x34
    [    3.459103] [<ffffffff809d0452>] handle_riscv_irq+0x2e/0x4c
    [    3.459133] [<ffffffff809d923e>] call_on_irq_stack+0x32/0x40
    
    So only flush the local TLB and let the lazy kfence page fault handling
    deal with the faults which could happen when a core has an old protected
    pte version cached in its TLB. That leads to potential inaccuracies which
    can be tolerated when using kfence.
    
    Fixes: 47513f243b45 ("riscv: Enable KFENCE for riscv64")
    Signed-off-by: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx
    Link: https://lore.kernel.org/r/20241209074125.52322-1-alexghiti@xxxxxxxxxxxx
    Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/riscv/include/asm/kfence.h b/arch/riscv/include/asm/kfence.h
index d887a54042aa..5d013dc52c0b 100644
--- a/arch/riscv/include/asm/kfence.h
+++ b/arch/riscv/include/asm/kfence.h
@@ -55,7 +55,9 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect)
 	else
 		set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
 
-	flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+	preempt_disable();
+	local_flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+	preempt_enable();
 
 	return true;
 }




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux