From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CF21382F3C for ; Sat, 9 May 2026 07:18:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778311120; cv=none; b=pUjPbQkxvyzL7kanvM2KKQQbHrNwiuun09H8wG+jOqg7oVEuBjRKzRbB3CbkGpP7I68sIkB4AxD8zvarstpxs6uB6h8myow9BBiKo0ANtrr+UpOHDytWYfeTqMhTFOpZWSqtRq1fsHGdFSVcv5hTFnNfCmK6qu0Z68H9wcQM4JM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778311120; c=relaxed/simple; bh=o7CPCGXOj2haokXsQESfPJhyteLvwzZMKjC6vcdU+L8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=gK31qQqhgkdbDSFGvpJTEovKFmDWnPKgrcT+SCqBQYDsU8Ijhk4gETBk0A8YGOsH/OGbWNuu7mGzqoVNR5k3I4K5aklBOrX1Z7BgP/crAqXLR+SeHENmBS1Y7ydJ7zWYicqlBp1aFb6JQg6QxAuYfo8VNcyIRLZOS+Up/BgAMl0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GCyvfSuo; arc=none smtp.client-ip=209.85.218.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GCyvfSuo" Received: by mail-ej1-f73.google.com with SMTP id a640c23a62f3a-b8704795d25so235924366b.2 for ; Sat, 09 May 2026 00:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778311116; x=1778915916; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=nWPmLPcUZniG40mmE6xEF7MYszlEp9VqvWN3AMo3/Bg=; b=GCyvfSuo4/3OaRHRdPDYOrTZrnoTyqXh/lmV/5Nm1yUUkrNXhdufSMQ8iZOymcsSFD o0oPD70vDF9Fp5BY+7lRZT5SAZ9vUdzc2BcfbmVvpchqCWBRira5muMRm6+pv8MJIdEC rFUv6L0StKnzXr2nikkzYTtB3hkyz2u2J8lWvhwMLbijbhk+32p9AAIwAkI7CPlrXdXv 26XWvsFgFuFEcV7NB87sSwHg5+i9dUQcRv4F6cwzYPaxYodKCYEMyms8PjsChXBFOON9 m569oPvlOv7DWFutmcD1XePZ9kTQew93eO4cr97mBpowAf1RhQsxWo6kQMXtJi56PQPF 22AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778311116; x=1778915916; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nWPmLPcUZniG40mmE6xEF7MYszlEp9VqvWN3AMo3/Bg=; b=APUZUvoSx/GIoyJBKcKggLj/cfqWcjhvo+RXc7aPGfv9nfnPpVPhgeRnkavweAw9uW b5Kys2uAy0diNv+Pe9ETx/9XVinXE6+jLXo60qN4KZM+HKfvXEjhmRGDS71LiVZsBQac /Wq+1wGO4gB/eMDUy/hxa06aVRXiHASmpTIlhzNnuNHpR6wVkXp3WN95CFOzDjXws1v8 6OzUXMq4ydLM7u9duGvpfcVzVMhPzZYqhE+1w/n7XzVs4zCy1GpSnX8ak929PyoWf/zF sBXThrZjMCx8hrhVLHcvGHp9SFuQ9xg2ae54I0ZmEmqQIE1TtduQjibMMk4VmvjQb4L7 KUdg== X-Forwarded-Encrypted: i=1; AFNElJ+iB9MkR6g14ojXFj9+/2JpC76WXczPlYanIYJ0pOq7BoC0WrDd+fglOyT0KctUCkn41yfgX/uW9Q==@vger.kernel.org X-Gm-Message-State: AOJu0YyA+DANQhcOFmkU47dtNp0uYHFdiC3X1TRybxCO2BSfMx7n7FPy wkrJ3thQ4L6tmB77ImbZXjasNNzKvgpwmUE/PXN1B5anPrWxYLRGwmtd/O0RvJlBPeqVSzNv7F5 jZW9bvKfxj92o7O/tEw== X-Received: from ejcbu12.prod.google.com ([2002:a17:907:930c:b0:bca:912a:8b1]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:3e93:b0:ba3:a8ef:3597 with SMTP id a640c23a62f3a-bc56c72d655mr930748266b.25.1778311115972; Sat, 09 May 2026 00:18:35 -0700 (PDT) Date: Sat, 9 May 2026 07:18:34 +0000 In-Reply-To: <20260508200157.kWPZI3p3@linutronix.de> Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260508-put-task-struct-many-v1-1-8341c18141a6@google.com> <20260508200157.kWPZI3p3@linutronix.de> Message-ID: Subject: Re: [PATCH] sched/task: always defer 'struct task_struct' destruction via RCU From: Alice Ryhl To: Sebastian Andrzej Siewior Cc: "Paul E. McKenney" , Andrea Righi , Boqun Feng , Changwoo Min , Clark Williams , David Vernet , Frederic Weisbecker , Ingo Molnar , Jens Axboe , Joel Fernandes , Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , Neeraj Upadhyay , Peter Zijlstra , Steven Rostedt , Tejun Heo , Uladzislau Rezki , Zqiang , 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 Content-Type: text/plain; charset="utf-8" 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