Re: [PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died

On Wed, Aug 19, 2026 at 2:30 AM Pavel Tikhomirov
<[email protected]> wrote:
>
>
>
> On 8/16/26 18:12, Andrei Vagin wrote:
> > When a posix timer is created targeting a specific thread (using
> > SIGEV_SIGNAL | SIGEV_THREAD_ID), it takes a reference to the target
> > struct pid in timer->it_pid. If the target thread subsequently
> > terminates, its numeric tid is freed and can be recycled for an
> > unrelated task. However, the timer holds its reference to the original
> > struct pid.
> >
> > show_timer() in /proc/[pid]/timers previously called pid_nr_ns()
> > directly on timer->it_pid without checking whether any task remained
> > attached to that struct pid. As a result:
> > 1. It reported the stale tid, which could mistakenly refer to a recycled
> >    pid.
> > 2. In the kernel, expired signals for dead target threads are dropped by
> >    posixtimer_send_sigqueue() because posixtimer_get_target() returns
> >    NULL, so the timer functionally acts as SIGEV_NONE.
> > 3. Checkpoint/restore tools (CRIU) parsing /proc/[pid]/timers would try
> >    to restore a timer with SIGEV_SIGNAL | SIGEV_THREAD_ID targeting a
> >    non-existent or unrelated thread.
> >
> > Check pid_has_task(timer->it_pid, timer->it_pid_type) in show_timer().
> > If the target task has died, override notify to SIGEV_NONE and report
> > PID 0 (e.g., 'notify: none/pid.0').
> >
> > Cc: Thomas Gleixner <[email protected]>
> > Signed-off-by: Andrei Vagin <[email protected]>
>
> Reviewed-by: Pavel Tikhomirov <[email protected]>
>
> Hopefully a useful note:
>
> Though the fixed interface is not full-proof by itself, e.g. there is
> still window that task alive at the time of check can be already dead at
> the time when userspace uses the reported pid.

Pavel, this isn't a unique problem. We can say that about any pid reported
in /proc.

>
> That gap probably can be closed easily from userspace, e.g. with taking pidfd
> on this reported pid and re reading the info (to make sure it's still the same
> task), or in CRIU we just have container processes frozen/ptrace-stopped so the
> reported pid task should not go away under us.

I think you answered your question:)

Thanks,
Andrei