From: Thomas Gleixner <tglx@kernel.org>
To: Zhu Jun <zhujun2@cmss.chinamobile.com>
Cc: anna-maria@linutronix.de, frederic@kernel.org,
linux-kernel@vger.kernel.org,
syzbot+0b91948d3c6b28c0d4c7@syzkaller.appspotmail.com,
Zhu Jun <zhujun2@cmss.chinamobile.com>
Subject: Re: [PATCH] timer_list: Annotate the clock event deadline snapshot
Date: Thu, 12 Nov 2026 11:31:46 +0100 [thread overview]
Message-ID: <875wy2tk6l.ffs@fw13> (raw)
In-Reply-To: <20261111084108.80870-1-zhujun2@cmss.chinamobile.com>
On Wed, Nov 11 2026 at 16:41, Zhu Jun wrote:
> print_tickdevice() reads next_event while the remote CPU can update it
> from its timer interrupt. The value is only printed to /proc/timer_list,
> so synchronizing the clock event device is unnecessary.
>
> Use a single diagnostic snapshot and mark the intentional race, as is
> already done for the tick scheduler statistics in print_cpu().
>
> Fixes: 289f480af87e ("[PATCH] Add debugging feature /proc/timer_list")
This really fixes nothing.
> Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
> ---
> kernel/time/timer_list.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
> index 0406bf4488e9..5f80af00729e 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -177,6 +177,7 @@ static void
> print_tickdevice(struct seq_file *m, struct tick_device *td, int cpu)
> {
> struct clock_event_device *dev = td->evtdev;
> + ktime_t next_event;
>
> touch_nmi_watchdog();
>
> @@ -199,7 +200,9 @@ print_tickdevice(struct seq_file *m, struct tick_device *td, int cpu)
> SEQ_printf(m, " mult: %u\n", dev->mult);
> SEQ_printf(m, " shift: %u\n", dev->shift);
> SEQ_printf(m, " mode: %d\n", clockevent_get_state(dev));
> - SEQ_printf(m, " next_event: %lld nsecs\n", (long long)dev->next_event);
> + /* Take a diagnostic snapshot without locking the clock event device. */
> + next_event = data_race(READ_ONCE(dev->next_event));
data_race(READ_ONCE()) ?
READ_ONCE() needs to be paired with WRITE_ONCE(), which is not there to
write dev->next_event. And no, we don't add it as there is zero value to
it for the regular usage outside of this debug code.
data_race() is sufficient to shut KCSAN up and you neither need an extra
variable nor a comment. data_race() in debug code is selfexplaining, no?
Thanks,
tglx
prev parent reply other threads:[~2026-11-12 10:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 8:41 Zhu Jun
2026-11-12 10:31 ` Thomas Gleixner [this message]
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=875wy2tk6l.ffs@fw13 \
--to=tglx@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+0b91948d3c6b28c0d4c7@syzkaller.appspotmail.com \
--cc=zhujun2@cmss.chinamobile.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
all inboxes | Powered by JetHome®