From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (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 49D02382382 for ; Sat, 9 May 2026 07:18:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778311120; cv=none; b=ZQHHptoZDr4S8Nq5zzcDsGyte0/Wn5GDMWxb6vIwOonAauHI0Lrc/SwlAq8hVIo0Fy2eORoW1azxfIcYL6ohpI/ZvV6xLmm9zTANr3HivOrt+OTU3sMA+WXpax3FKkkVPG3g/z37gzBultl/AhVGTjTvJ4Xb7Tvey54Y2isGHWo= 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=DXURPV2O; arc=none smtp.client-ip=209.85.218.74 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="DXURPV2O" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-bcc2320b2deso23855366b.1 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=lists.linux.dev; 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=DXURPV2OtbqVFBE4VHc8aeCBBsNYTuXqxPRvZmT4pP9hwjTtcDq/ZVcp95hdKvncx3 52faBFFT7G/7BJ+8cycyL+Us2qAFiZSWmw/QmvxpBF/4MXBzagOuMLiAQJDCzvk6YpJ0 cqVc8Xd4op0bqZVJjs+pLaF6bN4jMdO0gBWS3AKROSQXwyF4jsJGeA3m/4TpvNTKq3bn jqXnP7wZMbOq+D4/A3vFvQnSA4qJ0WUWcDVG51RXdXSr8vDQmugWbyS6d0e3FeJA+U4J 9ImdC7ojnYHdtDcCO/chwsTEo5/ewVTYyxEVzW7/gwjFZGsfbxNb/WqOvy0AVlSHHSap yrAw== 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=NPSRDT7fSiiD1Ad4P+DwKKCZT7OEdnZvMStt064M/dUS/mATIbFJ9M336hAu7BKTSs Se5L4YLLzR9+vMbyskGilbIet0b120xfTs79TpobmcgR0TJJQaNyNj6YbAeHyMkJQlEA /fNNn91gi1qywxiQ67J05Hg0yxbv4WU8nbtImmrnjgcJrswXli6D9q1m3j0b69H7TS3l rZAdi3FK+GWf5v58HFhN+sxhnjp5NvO78VXtR04UAbkpE+hMTQbhxvG0HVRA0nTuIzXz kT42ylTjWP1S4XH19a55Lr5ouzpbui0P6Tlo8AcOCYJ5AErkHvZ96dJD9XLHKNBNSsPz IeHw== X-Forwarded-Encrypted: i=1; AFNElJ+EUlp6EAs7AXtk5OkyVy0dIIuuqWzCspj0t/9toVbt0+Ne3dfJzxQxtNnwVLI3qKu+IT1UUlJozamomGibCQ==@lists.linux.dev X-Gm-Message-State: AOJu0Yz8ZtWRD9J/eEDFGlL0rWfCU/rl5TSNH9F7jZhnVnS76zNGrQD3 772ojP3T/BbHiFh+zty2rwuFhKuaqQrABfgpY14lxSAb3Dwhg6pz+0kD5K9WD3wYZ+AxLNX2lEW fsrTigt2VskDyksckZQ== 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: linux-rt-devel@lists.linux.dev 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