From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14A0A3F5BF3 for ; Fri, 7 Aug 2026 13:45:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786110349; cv=none; b=jFLwEODYVi9sd+IKp1OcM4+lSUDXIv7SuIBww3rpMF4/+TyQTLKAZWMyYaPqfIPTmxai8QaLnpYRAAzskxZPqZ3TAydlHVBpU4qFCDGDvxWuXpshBO2OzyaTdd5zsgz+RDlF0DTOx0AnQsOwnrwC0mw6kGLFXksKo3W4I8qsF/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786110349; c=relaxed/simple; bh=A2gDF3x29+SubqlsfGPR8RpMBOce48RM7X9rtVAgnvE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QIWhUX/xG4kE+SfdZH2F2uuVjAQCFBT+STF5a/3i1F31qfnPbQJacUJuDQnV/w7U0XyRbVxVVeoOFtxTRQ3DrSSWJigEDqFRsmUDAhVWvq4qfieQi7wh+LQ5We3QFjbeqPD9hElRW/wgGzlzbcORBaTPIYeAj4vQKEe3JNMvcbQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=LXi7TkzP; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="LXi7TkzP" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-47f92e3c14bso2969404f8f.0 for ; Fri, 07 Aug 2026 06:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786110333; x=1786715133; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=DrL6gBCAOxHb0LQHDdbrlJolZxiGNWOy/qwBrxrXEdw=; b=LXi7TkzPR4R3GAdYCufFK/K0p5gzHHjfEHJDGW8CVl91/4N4FuL5pDfsVrq7WZHkC8 vmc7QaN2PfPVJ7uW7F2YPDze9rcOQjBGPV43YmoHbud64JgHSab3ijv8MOYFhooNvMWg bNIS0C/+BUWPy6tj2G0//AIH/t5OpNAp6pkcbWfQ/c6V7RYa59ly8EzPpSV5m/STrulk u/PENH4C2qX5zTrUH6IB7b168oHzhCqAV8kgODcIFSpZXu49zFILYAwha5WKo6mg4h37 22MEfUG0Al6gbMTmnJjk2f3BriTjPsRWqi7/zXcgLWdulJGPqzdcM40Jf1brb6PZCVVR zwWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786110333; x=1786715133; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DrL6gBCAOxHb0LQHDdbrlJolZxiGNWOy/qwBrxrXEdw=; b=R1wV/taDmPwnAZQyYtig3NeOEIzorolV+foIvug1klLoxWJManAQoe7vAVTnzCH3YY AIxp9UYZTeNYBJmAXPmsayjSjQWiAaxXSN83eY+wTJXrd/2yzuVTAPGcwZYwxj6MfmcY 6ZPYPymyyKqNDNYSjiWxJbBjbBnRE6EWNh7MneWOfAYtzXw2cYXkDgW9ggDhA32wcKAG Q/UYCeEZAT/Y5eNaG2OILf7EupBl+Ak5DrUF1HxPCzoxMavym2qkmQc7byFQIeDh9nHs QQYecqt+Ef2si1MLLMnG1Ax9OjvyYuWsQwPOBuoE21chCkm8kB/uDwjz/CLQy3wLTlhi ROPg== X-Forwarded-Encrypted: i=1; AHgh+RoXSG8T0mZd/5VpfP14qYNjr6SIO2u6ympMj8wyE4Z1BlYUP+7zsL7Of8Flm8ceMGUPzbit4NXDefI2/n0=@vger.kernel.org X-Gm-Message-State: AOJu0YyVv8PAyXjpT4Nt0BoQnlf2mupFaNCVp7XG+pulQSAfa/T4JOd7 Z69cONvGZ0dY0MUCd7BlMWy2skayobkUpKOcG3IZtwNRj86J6Q5UyS8spG4CMZZckA== X-Gm-Gg: AR+sD13rFSNGOx0Zbwi+/U8x+jXyBABuL8JrDt+POQdFf3qQvO+7pLE+mhEE7SlrgbX 1YU9q0T0v6Gqw/b20Tszc3vmnvwQSuMsOoOjA0x35HEf6q8GhA1oSF7sJCpJBVpra56sH9vIIce 7nOjktYybcR8o0EMtSl8fYHk2mMOzetU5p5OJZ+uIFkO3elo+N49ZU611Pe4bN4kR9XcXHoVywy TiqxtTzQp9n9DjtUMa3gPxOGqKo2bV1e6RDeeupOES6w/jMNCZge4OMa9ejdMNDA7mLA0X8Goc8 6R83uIjYv0+4T/kW79r5GA/SHcvZSF7FwrSRBX00++iy1H1aAkbFHYY9jUo/kKWhFzg+h+OILce 7knswaxwvGf5+3OBUNxTFcFzHKqevFSy217HXREBRJ3QAbic0dGtRGtEaHGW4OnFf+Js5E6qNZE 8Wcl9nP+LUwSWSQAcTjzvF8HxMwhmKVnUaXBUAZk16TKTIL9ctdnQbuY5sc/WOnGGe0OAOOuxTH w1w4p4Cvr+ZQV/wFopdNTQT2ySiM7PqbCC4OG4czw== X-Received: by 2002:a5d:5e86:0:b0:47f:ebe3:ca31 with SMTP id ffacd0b85a97d-47fec62e00bmr38542831f8f.28.1786110332995; Fri, 07 Aug 2026 06:45:32 -0700 (PDT) Received: from elver.google.com (24.125.187.35.bc.googleusercontent.com. [35.187.125.24]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021e8d50sm5963422f8f.24.2026.08.07.06.45.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 06:45:32 -0700 (PDT) Date: Fri, 7 Aug 2026 13:45:28 +0000 From: Marco Elver To: Will Deacon Cc: "Paul E. McKenney" , dvyukov@google.com, Mark Rutland , Catalin Marinas , Jinjie Ruan , Ada Couprie Diaz , linux-arm-kernel@lists.infradead.org, "Peter Zijlstra (Intel)" , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Subject: Re: [PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched Message-ID: References: <13df4ff4-8594-4c37-b25f-860248a222cf@paulmck-laptop> <4fa802e7-6cfc-4cce-afee-c29b28171ad3@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.3.2 (2026-04-26) On Fri, Aug 07, 2026 at 02:19PM +0100, Will Deacon wrote: [...] > Ok, but then I don't understand how these accesses can race. They appear > to be on the same CPU, in the same IPI handler. The only way this could happen is with an NMI, but that's not the case here? I should have looked at the 2nd stack trace, and it seems to be clear that this is a false positive: KCSAN sets up a watchpoint on an address that is also accessed by __delay. One problem with disabling KCSAN in this CPU's context is that we'd fail to detect data races from nested interrupts. So yes, the best way forward is to disable KCSAN in the delay implementation. And I recall doing this for x86, which has this: [arch/x86/lib/Makefile] ... # KCSAN uses udelay for introducing watchpoint delay; avoid recursion. KCSAN_SANITIZE_delay.o := n So let's do this for arm64, too. Sorry for the noise. ------ >8 ------ >From cfea3a0c12b2e685ce04c28b1bd207f0e4c05a56 Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Fri, 7 Aug 2026 13:37:32 +0000 Subject: [PATCH] arm64: Disable KCSAN instrumentation in delay.o KCSAN relies on udelay() for injecting delays. To avoid recursively triggering a watchpoint, where KCSAN sets up watchpoint on an address that is accessed by udelay() in the same thread, disable instrumentation in arm64's delay implementation. Paul found a manifestation of this as follows: | BUG: KCSAN: data-race in __delay / set_need_resched_current | | read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8: | __delay+0xb0/0x378 | __udelay+0x4c/0x60 | kcsan_setup_watchpoint+0x3b4/0x820 | __tsan_unaligned_write4+0x228/0x26c | set_need_resched_current+0x138/0x1a8 | rcu_exp_handler+0x418/0x4a0 | __flush_smp_call_function_queue+0x36c/0x4a0 | generic_smp_call_function_single_interrupt+0x20/0x30 | ipi_handler+0xec/0x558 | handle_percpu_devid_irq+0x220/0x2a0 | generic_handle_domain_irq+0x84/0xb4 | gic_handle_irq+0x64/0x144 | call_on_irq_stack+0x30/0x48 | do_interrupt_handler+0x80/0xb8 | el1_interrupt+0x3c/0x60 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x6c/0x70 | smp_call_function_single+0x18c/0x25c | sync_rcu_exp_select_node_cpus+0x534/0x8bc | rcu_exp_sel_wait_wake+0x358/0xef4 | wait_rcu_exp_gp+0x30/0x44 | kthread_worker_fn+0x1b4/0x5dc | kthread+0x1d8/0x204 | ret_from_fork+0x10/0x20 | | write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8: | set_need_resched_current+0x138/0x1a8 | [...] This matches what is already done in arch/x86/lib/Makefile. Reported-by: "Paul E. McKenney" Fixes: dd03762ab608 ("arm64: Enable KCSAN") Signed-off-by: Marco Elver --- arch/arm64/lib/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile index 448c917494f3..b33e1ca4a781 100644 --- a/arch/arm64/lib/Makefile +++ b/arch/arm64/lib/Makefile @@ -1,4 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 + +# KCSAN uses udelay for introducing watchpoint delay; avoid recursion. +KCSAN_SANITIZE_delay.o := n + lib-y := clear_user.o delay.o copy_from_user.o \ copy_to_user.o copy_page.o \ clear_page.o csum.o insn.o memchr.o memcpy.o \ -- 2.55.0.654.g21b8a5bc05-goog