On 2026/05/21 17:38, Sebastian Andrzej Siewior wrote:
>> 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.

This patch already excludes hardirq / nmi contexts at the beginning of
kcov_remote_start()/kcov_remote_stop(). Therefore, only task / softirq
contexts can reach the location in question.

> 
>> 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?

Ditto.

> 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.

https://share.google/aimode/PveuuU5od6d1lAwit (expires in 7 days) says

  Non-PREEMPT_RT Kernel: in_task() returns false while executing a softirq.

  PREEMPT_RT Kernel: in_task() returns true while executing a softirq (unless
                     nested inside a hard interrupt or NMI).

Is this explanation wrong?