All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Andrea Righi <arighi@nvidia.com>, Boqun Feng <boqun@kernel.org>,
	 Changwoo Min <changwoo@igalia.com>,
	Clark Williams <clrkwllms@kernel.org>,
	 David Vernet <void@manifault.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,  Jens Axboe <axboe@kernel.dk>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	 Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	 Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	 Steven Rostedt <rostedt@goodmis.org>, Tejun Heo <tj@kernel.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	 Zqiang <qiang.zhang@linux.dev>,
	io-uring@vger.kernel.org, rcu@vger.kernel.org,
	 sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org,
	 linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH] sched/task: always defer 'struct task_struct' destruction via RCU
Date: Sat, 9 May 2026 07:18:34 +0000	[thread overview]
Message-ID: <af7fym1VhjYMw_h4@google.com> (raw)
In-Reply-To: <20260508200157.kWPZI3p3@linutronix.de>

On Fri, May 08, 2026 at 10:01:57PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-08 14:02:45 [+0000], Alice Ryhl wrote:
> > The sched/task.h header file currently exposes a tryget_task_struct()
> > function, but it is very risky to use it: If the last refcount of the
> > task is dropped using put_task_struct_many(), then the task is freed
> > right away without an RCU grace period.
> > 
> > This means that if the kernel contains a code path anywhere such that
> > the last refcount of a task may be dropped with put_task_struct_many(),
> > and it also contains a code path anywhere that tries to stash a task
> > pointer under rcu and use tryget_task_struct() on it, then if they ever
> > execute on the same 'struct task_struct', it results in a
> > use-after-free.
> 
> If the counter dropped to 0 then tryget_task_struct() won't increment
> it.

Yes. If the 'struct task_struct' hasn't been freed yet. What is the
scenario where it might be zero, but you are certain it is not yet
freed? If not rcu, then I guess this applies only to those cases where
__put_task_struct() itself removes the task from the relevant collection
when 'users' hits zero.

If tryget_task_struct() can only safely be used in that scenario, then I
think that's worth at least a comment in the header file, because at
first glance it's a surprising limitation.

> There is also task_struct::rcu_users which holds one `usage' on it
> and this RCU grace period we care about.

Sure, but I guess my question is: why does tryget_task_struct() exist?
The 'rcu_users' field is not the reason because 'usage' can't be zero
when using that field.

Alice

> The only reason why there is a RCU free here is because of RT and it was
> limited to RT only. Then a PI case came up (on RT again) I asked
> repeatedly to have it unconditional on RT and !RT. Which then did
> happen.
> 
> I don't think I would mind to align the two code paths but not as a
> "this might be UAF if" but to do the same "thing". The important RCU
> grace period happens via put_task_struct_rcu_user().
> 
> Sebastian

  reply	other threads:[~2026-05-09  7:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 14:02 [PATCH] sched/task: always defer 'struct task_struct' destruction via RCU Alice Ryhl
2026-05-08 20:01 ` Sebastian Andrzej Siewior
2026-05-09  7:18   ` Alice Ryhl [this message]
2026-05-08 21:38 ` Andrea Righi
2026-05-10 13:41   ` Alice Ryhl
2026-05-10 18:36     ` Andrea Righi

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=af7fym1VhjYMw_h4@google.com \
    --to=aliceryhl@google.com \
    --cc=arighi@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=bigeasy@linutronix.de \
    --cc=boqun@kernel.org \
    --cc=changwoo@igalia.com \
    --cc=clrkwllms@kernel.org \
    --cc=frederic@kernel.org \
    --cc=io-uring@vger.kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joelagnelf@nvidia.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qiang.zhang@linux.dev \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=urezki@gmail.com \
    --cc=void@manifault.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.