From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 874993E1CFA for ; Tue, 31 Mar 2026 16:20:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774974051; cv=none; b=F6+V7GQp1M0Dqk4em6m9QhSK88qh13KvJ8PeB1JQiC1PjAgd97XHG7+zgdiEI1PHS2Nhyw/d2eA7vgJNCn5MV4vYqa0RrNumlTfGFCNTRyU6SJxpVvitsMaFEaQzQhLNImNfC/CEd34rgXWNJSVl1JTR2KucdWsN8+VebgS0KTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774974051; c=relaxed/simple; bh=Skckb74KdBnV8+E7aXmFQFjtAKJYHMT2YXbPb3gpHhQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Kc5kt69qjOLh6yhK6CZ7wMdMDyMwYkO+bHchahvFVZXG10HNcQEGKu6YxZj9iuzueTq2wtMzv1NmtwIGNkXY5OGx554C8ZNiHpF2betGeG14A8xI3Bq3DLBq8FvgFoPBXpFCVuhEt2XzypxO/P4SMU2kegx/mIN0qkVmE22C2Go= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=B47tskhT; arc=none smtp.client-ip=209.85.215.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="B47tskhT" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-c70bfef17a4so4334449a12.2 for ; Tue, 31 Mar 2026 09:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774974050; x=1775578850; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=t53k6xqlseulquJHuVNZsyr/eU4NF62CkVK34QJvTOA=; b=B47tskhT6XG5BwzgtZp8TU7tlyS9WiwuChKJKdmvMT+T1tSH1NZCEn0THJsr93VKBW o8BK701N27RiT5BRqziA801/OmlsqXEO+8dWa6Kk5iqGKrqNnERyg/oHVMqF8wLg5mi6 1XKLqbiT8gkSjwkxLJoXFTohNizBfY5z/HLDL7wUnwPHY9jw6Kt4IIE9f8D6+o2BxDvE HRVCOJpxod8RhpAOIG9B6uxs/w9EIrH3A8saGj5o/LMILOMAyHn4x95jkf7XRGPU9k8+ LLMBGOHvGqbxcIeLlXSHeO1+OqqvV/SSIC7ySfg8bymvOW3k/k2xlRaX+KhKx36Odsi3 ypYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774974050; x=1775578850; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=t53k6xqlseulquJHuVNZsyr/eU4NF62CkVK34QJvTOA=; b=eTaeCLw/VgI60eCfe8GUdmVTbgp0HHfFL6DXgn4nJ3w+aj4ZP/cPzOiiKPz499oEtm gSgWFR4K2jdVjvsHjnE8/hb1QkFvDvbLweMkDctPKX7hAGq8kFXbAiWCXTEEq5u85pv3 JjzGFYoHUwOyAEDGkyWgceOpLnQiABF0jofNrzXbRBkJVvMaZlJiO4j6VJ42qtcftcmn x59Fe7W7SPkaIgkdm/vflpHAowaWmABacbkiD2P12QuZwuyp2XnPShqZ8DfPf6WE7Sqd JAQTgwESet4Mzb6qyuDG0reo/Eg0pDOu7jjoA9y1CjXIVw97EyEqZs6kRTgAdP54NAT4 n5bw== X-Forwarded-Encrypted: i=1; AJvYcCXFPBthAifiwJLR5h1bDqdW81c1JcP+3UAE7RoN/NvOqZ1TUUen2Bd/DKR1sVHm4YjQybzkZhv4yLKUcNg=@vger.kernel.org X-Gm-Message-State: AOJu0YxuXZUPcH/fh11WZrYHHX4J/y7hzWQUHPvXs5d+fBaOlo4wSCzE LvWEGYhFq4SVTsfkUOaPlSAZ6TFK08DzQmegep1EVtF1Hww54NtkUlA8 X-Gm-Gg: ATEYQzy/x1di9Tu4SNaCA/O4CC3A1W9AzIUpYU5BBdbV+ix4FY4D6eqvL/pGFFREcWM kv7ezluVlRWDAQ+/OuiBpTLfGm1spYeOASL0S6EbBhq3DiwvySZVP6Clrsvn08lBzO0FeA68ypn yDuN9xfaDpw0XqL3TmruHUtRIHAU+apwQkzo5QllJe08KPKU2xEOlnkgIAmFS1OMncU6ODqIoCM i4n5pwA83rbgVg8V+J4UAPB9ivlaE+p8Y5Rux5i49jAVr2ZJXDf09AXvXB0pngxYHwHy3N+5fI9 wDAk1JmJJJxKl0yX4ZczaU2jLsh6aW2NQ//apncKXk9q9csOsTLAjQblFQJib/3WaA05AdUzSoX 6fIvbKtRRouHpZlZcn4xwnPDOR0f0FLF24GdlvyFNbCCxv17kl1Jb/JQGcpJXa3qHIS1CT42htw AlBtpylVL82AcMhHKOLrfNHHI= X-Received: by 2002:a05:6a20:914b:b0:398:7ed3:a001 with SMTP id adf61e73a8af0-39c8787a81bmr18924760637.2.1774974049696; Tue, 31 Mar 2026 09:20:49 -0700 (PDT) Received: from ubuntu24.lan ([14.219.52.214]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c76b9c20473sm991578a12.24.2026.03.31.09.20.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 09:20:49 -0700 (PDT) From: Yiyang Chen To: akpm@linux-foundation.org Cc: bsingharora@gmail.com, cyyzero16@gmail.com, fan.yu9@zte.com.cn, linux-kernel@vger.kernel.org, stable@vger.kernel.org, thomas.orgis@uni-hamburg.de, wang.yaxin@zte.com.cn Subject: Re: [PATCH 1/2] taskstats: set version in TGID exit notifications Date: Wed, 1 Apr 2026 00:20:40 +0800 Message-ID: <20260331162040.52631-1-cyyzero16@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260330142909.3a5fe0ce22798a8cc34a8abe@linux-foundation.org> References: <20260330142909.3a5fe0ce22798a8cc34a8abe@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Mar 31, 2026 at 5:29 AM Andrew Morton wrote: > > On Mon, 30 Mar 2026 03:00:40 +0800 Yiyang Chen wrote: > > > delay accounting started populating taskstats records with a valid > > version field via fill_pid() and fill_tgid(). > > > > Later, commit ad4ecbcba728 ("[PATCH] delay accounting taskstats > > interface send tgid once") changed the TGID exit path to send the > > cached signal->stats aggregate directly instead of building the outgoing > > record through fill_tgid(). Unlike fill_tgid(), fill_tgid_exit() only > > accumulates accounting data and never initializes stats->version. > > > > As a result, TGID exit notifications can reach userspace with > > version == 0 even though PID exit notifications and > > TASKSTATS_CMD_GET replies carry a valid taskstats version. > > > > Set stats->version = TASKSTATS_VERSION after copying the cached TGID > > aggregate into the outgoing netlink payload so all taskstats records are > > self-describing again. > > > > Fixes: ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") > > Thanks, lol, 20 years ago. > > Can you explain how others can trigger this?  Some combination of > steps which results in the bad output? Yes. This is easy to reproduce with `tools/accounting/getdelays.c`. I have a small follow-up patch for that tool which: 1. increases the receive buffer/message size so the pid+tgid combined exit notification is not dropped/truncated 2. prints `stats->version`. With that patch, the reproducer is: Terminal 1: ./getdelays -d -v -l -m 0 Terminal 2: taskset -c 0 python3 -c 'import threading,time; t=threading.Thread(target=time.sleep,args=(0.1,)); t.start(); t.join()' That produces both PID and TGID exit notifications for the same process. The PID exit record reports a valid taskstats version, while the TGID exit record reports `version 0`. > > > Cc: stable@vger.kernel.org > > Is there a chance of breaking existing userspace here?  Some existing > userspace code which is expecting 0 here and will get surprised by this > change? In practice, userspace uses `taskstats.version` to decide which fields are present in `struct taskstats`, i.e. as a schema/version discriminator. A zero version does not describe a valid taskstats layout, so it is hard to see how userspace could use `0` as a meaningful or useful distinction here. So I do not think fixing this in mainline should break sensible userspace. It just restores consistency of the taskstats version semantics across `TASKSTATS_CMD_GET`, PID exit notifications, and TGID exit notifications. To be honest, I'm also not sure if this should backport to stable. But I think mainline should still fix it. Thanks, Yiyang