Re: [PATCH v3] kcov: move kcov_remote_data to task_struct for RT and remove local_lock

[Sebastian Andrzej Siewior]

On 2026-05-09 17:09:44 [+0900], Tetsuo Handa wrote:
> 3. In non-RT kernels, softirqs do not nest, so no concurrent access to
>    per-CPU data occurs between softirqs.
> 4. In RT kernels, while softirqs can be preempted, this patch moves the
>    KCOV state from per-CPU variables to task_struct (per-task), eliminating
>    the contention on shared per-CPU resources.

This is correct: The softirq handling can be preempted _and_ another
softirq can be handled. softirq handling is still per-task. However this
could mess up the per-CPU data if it is not meant to be shared by two
tasks doing softirq in parallel.

> By moving kcov_remote_data to task_struct for RT kernels and replacing
> the in_task() check with !in_serving_softirq(), we ensure consistent

This I don't get. in_task() returns only true if it is a pure
task-context: no hardirq, or softirq handling. in_serving_softirq()
returns true if softirqs are handled but also if the current context got
interrupted by a hardirq _while_ softirqs were served. That is why there
is the in_softirq_really() to limit it just the softirq-only case.

> context detection. Since the data is now isolated per-task and not accessed
> by hardirqs, the local_lock (and the original local_irq_save) is no longer
> necessary and is removed to reduce overhead.
> 
> Changes:
> 
> * Move remote coverage state from kcov_percpu_data to task_struct under
>   CONFIG_PREEMPT_RT.
> * Replace in_task() with !in_serving_softirq() in kcov_remote_start/stop()
>   for accurate context tracking.

Doesn't this exclude softirq handling and allows hardirq/ nmi?

> Only compile tested. I don't have environment to measure how not
> preallocating CONFIG_KCOV_IRQ_AREA_SIZE bytes of buffers and
> add to the global pool in kcov_init() impacts reliability / performance.
> Please be sure to test this patch using CONFIG_PREEMPT_RT=y and
> CONFIG_PREEMPT_RT=n kernels in local syzkaller environment before
> sending upstream.
> 
> This patch is expected to address various KCOV related reports.
> But I don't add Closes: lines because we can't tell whether this patch
> alone is sufficient for marking as Closes:. We will find the answer
> some time after being sent to upstream.
> 
>   https://syzkaller.appspot.com/bug?extid=90984d3713722683112e
>   https://syzkaller.appspot.com/bug?extid=47cf95ca1f9dcca872c8
>   https://syzkaller.appspot.com/bug?extid=8a173e13208949931dc7
>   https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc
>   https://syzkaller.appspot.com/bug?extid=e6686317bd9fe911591a

None of these have a reproducer which is unfortunate. The parallel
softirq handling is only possible since commit 3253cb49cbad4 ("softirq:
Allow to drop the softirq-BKL lock on PREEMPT_RT") which is v6.18-rc1.
This is true most of these reports since they are from 2026 except for
two in the 3f51ad7ac3ae57a6fdcc report. But this might be another issue
which got fixed since then.

If handling softirqs in parallel might be indeed a reasonable solution.
You would need to use the per-task area instead per-CPU for this in the
softirq case on PREEMPT_RT. But the other checks, such as in_task()
work as intended on both.

Sebastian