From: Will Deacon <will@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Marco Elver <elver@google.com>,
"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jinjie Ruan <ruanjinjie@huawei.com>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-arm-kernel@lists.infradead.org, dvyukov@google.com
Subject: Re: [PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched
Date: Mon, 10 Aug 2026 16:15:06 +0100 [thread overview]
Message-ID: <annq-ldauKsp1wq5@willie-the-truck> (raw)
In-Reply-To: <5c607693-7fce-4b24-a648-95ab96db6691@paulmck-laptop>
On Fri, Aug 07, 2026 at 11:44:56AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 07, 2026 at 01:45:28PM +0000, Marco Elver wrote:
> > 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.
>
> Thank you both!
>
> I will revert my arm64-specific patch and apply this one. Testing will
> take some time, and I will get you know how it goes.
Cheers, Paul.
I've queued it up in the arm64 tree, so please shout if you run into any
problems.
Will
next prev parent reply other threads:[~2026-08-10 15:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 23:59 [PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched Paul E. McKenney
2026-07-31 12:51 ` Mark Rutland
2026-07-31 16:44 ` Paul E. McKenney
2026-07-31 18:39 ` Paul E. McKenney
2026-08-06 11:58 ` Will Deacon
2026-08-06 17:25 ` Paul E. McKenney
2026-08-07 12:06 ` Will Deacon
2026-08-07 12:21 ` Marco Elver
2026-08-07 13:19 ` Will Deacon
2026-08-07 13:45 ` Marco Elver
2026-08-07 18:44 ` Paul E. McKenney
2026-08-10 15:15 ` Will Deacon [this message]
2026-08-10 18:47 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=annq-ldauKsp1wq5@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=ruanjinjie@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox