From: Oleg Nesterov <oleg@redhat.com>
To: Daehyeon Ko <4ncienth@gmail.com>, Christian Brauner <brauner@kernel.org>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
syzbot+0aee5e8066eddbbe7397@syzkaller.appspotmail.com,
syzbot+e8b3520b53e78e90034e@syzkaller.appspotmail.com
Subject: Re: [PATCH v2] exit: hold a reference to thread_pid across proc_flush_pid
Date: Mon, 31 Aug 2026 16:58:58 +0200 [thread overview]
Message-ID: <apWWsqOzJny1v4ab@redhat.com> (raw)
In-Reply-To: <20260831001221.3755948-1-4ncienth@gmail.com>
On 08/31, Daehyeon Ko wrote:
>
> Commit 0a36bad01731 ("release_task: kill the no longer needed
> get/put_pid(thread_pid)") removed the reference around proc_flush_pid().
> It assumed that free_pids(post.pids) at the end of release_task() would
> keep thread_pid alive until then.
>
> That assumption is wrong. __change_pid() only records a detached PID in
> post.pids when pid_has_task() is false for every PIDTYPE. If another task
> still uses the exiting task's PID as its process group or session ID,
> __unhash_process() removes the exiting task's PIDTYPE_PID link but leaves
> the PID out of post.pids. release_task() therefore holds no reference to
> it after dropping tasklist_lock.
>
> The other task can then remove the remaining PIDTYPE links. Its
> free_pids() call schedules delayed_put_pid(), and the RCU callback can free
> the PID before the first release_task() reaches proc_flush_pid().
Much better, thanks. The comment above get_pid(task_pid(p)) looks better too.
Acked-by: Oleg Nesterov <oleg@redhat.com>
> A tested source reproducer is available privately on request. No
> controlled read or write, information leak, or privilege escalation is
> claimed. The mainline patch applies directly to v6.19.y and newer;
> v6.16.y through v6.18.y need a context-adjusted backport.
Up to you and Christian (I am hoping we can take your fix), but I think
that this paragraph should be removed from the changelog... At least the
"A tested source reproducer is available privately on request." part.
Heh. I didn't even know that 0a36bad01731 was backported to stable. Why?
I guess I missed some AUTOSEL email...
Thanks,
Oleg.
next prev parent reply other threads:[~2026-08-31 14:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 0:12 [PATCH v2] exit: hold a reference to thread_pid across proc_flush_pid Daehyeon Ko
2026-08-31 14:58 ` Oleg Nesterov [this message]
2026-09-04 9:40 ` Christian Brauner
2026-09-01 8:01 ` Bradley Morgan
2026-09-04 9:40 ` Christian Brauner
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=apWWsqOzJny1v4ab@redhat.com \
--to=oleg@redhat.com \
--cc=4ncienth@gmail.com \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=syzbot+0aee5e8066eddbbe7397@syzkaller.appspotmail.com \
--cc=syzbot+e8b3520b53e78e90034e@syzkaller.appspotmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.