Re: [PATCH v2 0/6] kcov: Suppress timer and scheduler coverage leaks

[Alexander Potapenko]

On Tue, Sep 1, 2026 at 7:50 AM Karl Mehltretter <kmehltretter@xxxxxxxxx> wrote:
>
> On Tue, Aug 11, 2026 at 05:41:05PM +0100, Karl Mehltretter wrote:
> >
> > Add a nestable KCOV_PAUSED bit and a kcov_pause guard. Use the guard for
> > deferred hrtimer rearm, __schedule(), the try_to_wake_up() wakeup body
> > and wake_up_new_task(). This suppresses their instrumented callees
> > without excluding those callees from task-context coverage.
> >
>
> Andrey, Alexander, Dmitry,
>
> Could you please take a look at this series from the KCOV side?

Hi Karl,

>
> It fixes the CONFIG_KCOV_SELFTEST failures covered by this series. Some
> architectures still need further architecture-specific KCOV
> instrumentation exclusions.
>
> The three syzkaller A/B pairs from the cover letter also suggest
> better coverage: at matched execution counts, the patched kernels had
> 14-19% more coverage and 42-54% larger corpora.
>
> Do you think the pause mechanism and the places where it is used make
> sense? Do you want me to continue with a v3?

I think it makes sense, although it would be nice to try to minimize
the number of points where we insert kcov_pause()/kcov_resume()
Perhaps we could piggyback on some common scheduler action (e.g.
locking) to do that?

If Peter is fine with these annotations being open-coded in
kernel/sched/core.c, then I'm also fine.

> I also looked at the Sashiko dashboard report:
>
> https://sashiko.dev/#/patchset/20260811154111.64669-1-kmehltretter@xxxxxxxxx
>
> I don't think the remaining warning about reordering or removing the
> kcov_mode stores is real for these call sites.

I think consistently using READ_ONCE/WRITE_ONCE here is better.
See my suggestion of converging the flag functions in "kcov: Add a
kcov_pause guard".

> One small change opportunity for v3: In try_to_wake_up(), I would take
> the kcov_pause guard before the preempt guard. Cleanup then runs
> preempt_enable() while KCOV is still paused and resumes KCOV afterwards.

Agreed.

> I would also replace "uninstrumented" with "built without KCOV
> instrumentation" to avoid the ambiguity Peter pointed out.

Ack, this is indeed clearer.

> Separately, I will look at turning Peter's IRQ-exit preempt-count
> proposal into a standalone patch for instrumentation in general,
> especially KCSAN. It does not replace this KCOV series, since it only
> covers work run directly from IRQ exit.

Fixing the IRQ exit should also help with some KMSAN false positives,
so I am all for it.