On Wed, Oct 28, 2026 at 04:31:17AM +0100, Karl Mehltretter wrote:
> Very early hardirq entry code needs to update the preempt count before
> instrumentable debug and tracing code can run. Conversely, hardirq return
> code needs to finish instrumentable validation and latency tracing before
> raw teardown.
>
> Add a small hardirq-entry header with irqentry_hardirq_count_start() to
> stage the raw HARDIRQ_OFFSET addition and record whether it was applied in
> an opaque cookie. With DEBUG_PREEMPT and without separate reschedule bits,
> route an already-negative count through a noinstr slow helper which
> preserves the existing DEBUG_LOCKS_WARN_ON() oops short circuit. Add
> irqentry_hardirq_count_finish() to report a rejected addition or complete
> post-add debug checks and latency tracing, and add
> irqentry_hardirq_count_sub_prepare() for validation and tracing before a
> raw subtraction. Keep preempt_count_add() and preempt_count_sub() behavior
> and ordering unchanged.
>
> Keep latency tracing in each calling path so CALLER_ADDR0 identifies the
> caller. Force the start and stop helpers inline because trace provenance
> depends on their stack frames.
Urgh, so much crazy.
So WARNs in noinstr code are 'fine'. That is, they should not happen, if
they do, bad things have happened and we need the warning out ASAP, if
it takes the machine down, too bad. See the
instrumentation_{begin,end}() markers in x86 asm/bug.h.
But yes, the tracing needs to go. But moving that around should not be
this ugly and also, that will give you the opportunity to fix
preempt_{en,dis}able_notrace(), since they currently also skip the bound
checks.
