From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
To: Andrei Vagin <avagin@google.com>,
Thomas Gleixner <tglx@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] proc: Report SIGEV_NONE in /proc/pid/timers if target task has died
Date: Wed, 19 Aug 2026 11:27:47 +0200 [thread overview]
Message-ID: <bfd5e627-6ba7-403b-8e42-e3e09f9eb106@virtuozzo.com> (raw)
In-Reply-To: <20260816161216.984580-1-avagin@google.com>
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 <tglx@linutronix.de>
> Signed-off-by: Andrei Vagin <avagin@google.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
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.
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.
> ---
> fs/proc/base.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 780f81259052..e3a6ea4fffea 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2519,17 +2519,23 @@ static int show_timer(struct seq_file *m, void *v)
> struct k_itimer *timer = hlist_entry((struct hlist_node *)v, struct k_itimer, list);
> struct timers_private *tp = m->private;
> int notify = timer->it_sigev_notify;
> + pid_t nr = 0;
>
> guard(spinlock_irq)(&timer->it_lock);
> if (!posixtimer_valid(timer))
> return 0;
>
> + if (timer->it_pid && pid_has_task(timer->it_pid, timer->it_pid_type))
> + nr = pid_nr_ns(timer->it_pid, tp->ns);
> + else
> + notify = SIGEV_NONE;
> +
> seq_printf(m, "ID: %d\n", timer->it_id);
> seq_printf(m, "signal: %d/%px\n", timer->sigq.info.si_signo,
> timer->sigq.info.si_value.sival_ptr);
> seq_printf(m, "notify: %s/%s.%d\n", nstr[notify & ~SIGEV_THREAD_ID],
> (notify & SIGEV_THREAD_ID) ? "tid" : "pid",
> - pid_nr_ns(timer->it_pid, tp->ns));
> + nr);
> seq_printf(m, "ClockID: %d\n", timer->it_clock);
>
> return 0;
--
Best regards, Pavel Tikhomirov
Senior Software Developer, Virtuozzo.
next prev parent reply other threads:[~2026-08-19 9:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 16:12 Andrei Vagin
2026-08-19 9:27 ` Pavel Tikhomirov [this message]
2026-08-20 18:10 ` Andrei Vagin
2026-08-30 1:02 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bfd5e627-6ba7-403b-8e42-e3e09f9eb106@virtuozzo.com \
--to=ptikhomirov@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@google.com \
--cc=criu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®