From: sashiko-bot@kernel.org
To: "Tobias Schaffner" <tobias.schaffner@siemens.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC 1/3] rv: add per-edge dwell-time statistics primitive
Date: Thu, 27 Aug 2026 07:34:17 +0000 [thread overview]
Message-ID: <20260827073417.CA2091F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260827072400.45734-2-tobias.schaffner@siemens.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] NMI Deadlock / Lock Reentrancy on 32-bit architectures
--
commit 29c9d40bef06feb46125ab67ac5762b58ace9c11
Author: Tobias Schaffner <tobias.schaffner@siemens.com>
rv: add per-edge dwell-time statistics primitive
Add a small primitive that records, per automaton edge, how long the
monitor dwelled before taking it with a count, a sum and a maximum.
The counters are kept in local64_t variables so a monitor's hot path
can update them without disabling interrupts.
> diff --git a/include/linux/rv_edge_stat.h b/include/linux/rv_edge_stat.h
> new file mode 100644
> index 0000000000000..751de8074dcc3
> --- /dev/null
> +++ b/include/linux/rv_edge_stat.h
[ ... ]
> +static __always_inline
> +void rv_edge_stat_account(struct rv_edge_stat *s, u64 dwell_ns)
> +{
> + s64 max;
> +
> + local64_inc(&s->count);
> + local64_add(dwell_ns, &s->sum_ns);
> +
> + /* Keep the largest dwell; retry only if a nested update raced us. */
> + max = local64_read(&s->max_ns);
> + while (dwell_ns > (u64)max) {
> + s64 prev = local64_cmpxchg(&s->max_ns, max, dwell_ns);
[Severity: High]
Could this cause an NMI deadlock on 32-bit architectures?
The commit message notes these counters are lock-free, but on 32-bit platforms
lacking native 64-bit atomics (e.g., ARMv6 or RISC-V 32 with
CONFIG_GENERIC_ATOMIC64=y), local64_t operations fall back to atomic64_t.
The generic atomic64 implementation uses a hashed array of spinlocks acquired
via local_irq_save(), which disables regular interrupts but not NMIs.
If an NMI interrupts rv_edge_stat_account() while it holds one of these
non-reentrant spinlocks, and the NMI handler triggers an RV monitor event
that hashes to the same lock, would the CPU deadlock attempting to acquire
the already-held spinlock?
Does this implementation need an explicit check to abort if
IS_ENABLED(CONFIG_GENERIC_ATOMIC64) && in_nmi(), similar to the protection
used in the trace ring buffer?
> +
> + if (prev == max)
> + break;
> + max = prev;
> + }
> +}
> +
> +#endif /* _LINUX_RV_EDGE_STAT_H */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260827072400.45734-1-tobias.schaffner@siemens.com?part=1
next prev parent reply other threads:[~2026-08-27 7:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 7:23 [RFC 0/3] rv: per-edge dwell-time statistics for per-cpu monitors Tobias Schaffner
2026-08-27 7:23 ` [RFC 1/3] rv: add per-edge dwell-time statistics primitive Tobias Schaffner
2026-08-27 7:34 ` sashiko-bot [this message]
2026-08-27 8:22 ` Gabriele Monaco
2026-08-27 10:10 ` Tobias Schaffner
2026-09-01 7:37 ` Gabriele Monaco
2026-08-27 7:23 ` [RFC 2/3] rv: add per-monitor edge-stat facility and stats file Tobias Schaffner
2026-08-27 7:39 ` sashiko-bot
2026-08-31 15:20 ` Gabriele Monaco
2026-08-27 7:24 ` [RFC 3/3] rv: collect per-edge dwell time for per-cpu DA/HA monitors Tobias Schaffner
2026-08-27 7:37 ` sashiko-bot
2026-08-27 8:18 ` [RFC 0/3] rv: per-edge dwell-time statistics for per-cpu monitors Gabriele Monaco
2026-08-27 18:21 ` Tobias Schaffner
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=20260827073417.CA2091F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tobias.schaffner@siemens.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.