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

[Andrei Vagin]

On Sat, Aug 29, 2026 at 6:02 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sun, 16 Aug 2026 16:12:15 +0000 Andrei Vagin <avagin@xxxxxxxxxx> 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.
>
> This sounds like a somewhat significant issue for CRIU but that's just
> me wildly guessing.
>
> > 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').
>
> No Fixes: and no cc:stable?  Maybe my guess was wrong?

I was not sure this "qualifies" as a regression, as this behavior has
existed since /proc/[pid]/timers was introduced more than 10 years ago.

In CRIU, we already have a workaround checking whether the process has a
thread with the specified TID. The only edge case this workaround cannot
handle is if the original thread dies and a new thread is later created
reusing that same recycled TID. This is a reason why this kernel change
is required.

The proper "fixes" tag is:
Fixes: 57b8015e07a7 ("posix-timers: Show sigevent info in proc file")

Thanks,
Andrei