linux.git/kernel/taskstats.c, branch v7.3-rc2

taskstats: fold the two cpumask handlers into one

2026-08-13T22:42:05+00:00

cmd_attr_register_cpumask() and cmd_attr_deregister_cpumask() differed
only in which attribute they parsed and which action they passed on, so
take both as arguments.  __free(free_cpumask_var) then removes the goto.

No functional change.

Link: https://lore.kernel.org/20260728202104.17839-3-include@grrlz.net
Signed-off-by: Bradley Morgan 
Cc: Balbir Singh 
Signed-off-by: Andrew Morton

taskstats: drop the dead NULL attribute check in parse()

2026-08-13T22:42:05+00:00

Patch series "taskstats: tidy up the cpumask command path".

Two small cleanups from reading kernel/taskstats.c. No functional change in
either one.


This patch (of 2):

taskstats_user_cmd() only calls the cpumask handlers after checking the
same info->attrs[] entry, so parse() never sees a NULL attribute.  Drop
the check and its odd "return 1", which no caller tested for anyway.

No functional change.

Link: https://lore.kernel.org/20260728202104.17839-1-include@grrlz.net
Link: https://lore.kernel.org/20260728202104.17839-2-include@grrlz.net
Signed-off-by: Bradley Morgan 
Cc: Balbir Singh 
Signed-off-by: Andrew Morton

taskstats: fix cpumask parsing cutting off the last character

2026-08-05T18:20:13+00:00

parse() hands nla_strscpy() len as dstsize, and nla_strscpy() copies at
most dstsize - 1 bytes.  When the attr payload comes in without a trailing
NUL, srclen == len >= dstsize and the last character of the cpumask string
gets cut off.  Register "0-15" and you are silently listening on "0-1",
exit data for the rest never shows up.

The bug only bites when the sender doesn't NUL terminate the payload;
senders that include the NUL were always fine (srclen gets decremented for
the trailing NUL, so srclen < dstsize).  Thats probably why this survived
20 years.  And the policy is NLA_STRING, not NLA_NUL_STRING, so a payload
without the trailing NUL is legit input here.

Skip the kmalloc/nla_strscpy dance entirely and use nla_strdup(), which
already allocates srclen + 1 and terminates.  The nla_len() bounds checks
stay as they were.

Link: https://lore.kernel.org/EC49FE41-7F5F-41E0-A07A-ABEB8ECA514D@grrlz.net
Fixes: f9fd8914c1ac ("[PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks")
Signed-off-by: Bradley Morgan 
Reported-by: Oleg Deomi 
Closes: https://lore.kernel.org/CAByWkfZ6b1=3H9pwkz-dDQOs9cZaF-HYQ6b9Yb0=Hq2r1Vv_Pw@mail.gmail.com
Reviewed-by: Andrew Morton 
Cc: Balbir Singh 
Cc: 
Signed-off-by: Andrew Morton

taskstats: return -EBADF when cgroupstats receives an invalid fd

2026-08-04T04:10:13+00:00

Patch series "taskstats: fix cgroupstats invalid fd handling and add
selftests".

This series fixes an issue where cgroupstats mishandles invalid file
descriptors, and introduces a functional kselftest to prevent regressions.

When an invalid file descriptor is passed via CGROUPSTATS_CMD_ATTR_FD,
cgroupstats_user_cmd() returns 0 instead of an error code. This leads to
two broken behaviors depending on netlink flags:
- Callers without NLM_F_ACK block indefinitely on recv().
- Callers with NLM_F_ACK receive a misleading success ACK (errno == 0)
  but no actual statistics payload.

The first patch addresses this by returning -EBADF when the fd cannot be
resolved.  The second patch adds a comprehensive kselftest covering both
the valid cgroup v1 query and the invalid fd paths (with and without
NLM_F_ACK) to ensure the fixes work as intended.


This patch (of 2):

cgroupstats_user_cmd() returns 0 without sending a reply or a netlink
error when the fd passed via CGROUPSTATS_CMD_ATTR_FD does not resolve to
an open file in the caller's table.  As a result:

- clients that did not set NLM_F_ACK block on recv() indefinitely
  waiting for a CGROUPSTATS_CMD_NEW message that is never emitted;

- clients that set NLM_F_ACK receive a misleading "success" ACK (errno
  == 0) with no statistics payload.

Return -EBADF instead so the netlink layer propagates the error to
userspace as expected.

Link: https://lore.kernel.org/cover.1783713230.git.cyyzero16@gmail.com
Link: https://lore.kernel.org/b4fd9e288e4a48efebaf41b4ffcdb204b06675c4.1783713230.git.cyyzero16@gmail.com
Signed-off-by: Yiyang Chen 
Acked-by: Balbir Singh 
Cc: Dr. Thomas Orgis 
Signed-off-by: Andrew Morton

taskstats: retain dead thread stats in TGID queries

2026-05-29T04:24:41+00:00

Patch series "taskstats: fix TGID dead-thread stat retention", v3.

This series fixes a taskstats TGID aggregation bug where fields added in
the TGID query path were not preserved after thread exit, and adds a
kselftest covering the regression.

The first patch keeps the cached TGID aggregate used for dead threads in
step with the fields already accumulated for live threads, and also fixes
the final TGID exit notification emitted when group_dead is true.

The second patch adds a kselftest that verifies TGID CPU stats do not
regress after a worker thread exits and has been reaped.


This patch (of 2):

fill_stats_for_tgid() builds TGID stats from two sources: the cached
aggregate in signal->stats and a scan of the live threads in the group.

However, fill_tgid_exit() only accumulates delay accounting into
signal->stats.  This means that once a thread exits, TGID queries lose the
fields that fill_stats_for_tgid() adds for live threads.

This gap was introduced incrementally by two earlier changes that extended
fill_stats_for_tgid() but did not make the corresponding update to
fill_tgid_exit():

- commit 8c733420bdd5 ("taskstats: add e/u/stime for TGID command")
  added ac_etime, ac_utime, and ac_stime to the TGID query path.
- commit b663a79c1915 ("taskstats: add context-switch counters")
  added nvcsw and nivcsw to the TGID query path.

As a result, those fields were accounted for live threads in TGID queries,
but were dropped from the cached TGID aggregate after thread exit.  The
final TGID exit notification emitted when group_dead is true also copies
that cached aggregate, so it loses the same fields.

Factor the per-task TGID accumulation into tgid_stats_add_task() and use
it in both fill_stats_for_tgid() and fill_tgid_exit().  This keeps the
cached aggregate used for dead threads aligned with the live-thread
accumulation used by TGID queries.

Link: https://lore.kernel.org/cover.1776094300.git.cyyzero16@gmail.com
Link: https://lore.kernel.org/abd2a15d33343636ab5ba43d540bcfe508bd66c7.1776094300.git.cyyzero16@gmail.com
Fixes: 8c733420bdd5 ("taskstats: add e/u/stime for TGID command")
Fixes: b663a79c1915 ("taskstats: add context-switch counters")
Signed-off-by: Yiyang Chen 
Acked-by: Balbir Singh 
Cc: Dr. Thomas Orgis 
Cc: Oleg Nesterov 
Cc: Wang Yaxin 
Cc: Yang Yang 
Cc: 
Signed-off-by: Andrew Morton

taskstats: set version in TGID exit notifications

2026-04-15T09:15:02+00:00

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.

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`.


This patch (of 2):

Set stats->version = TASKSTATS_VERSION after copying the cached TGID
aggregate into the outgoing netlink payload so all taskstats records are
self-describing again.

Link: https://lkml.kernel.org/r/ba83d934e59edd431b693607de573eb9ca059309.1774810498.git.cyyzero16@gmail.com
Fixes: ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once")
Signed-off-by: Yiyang Chen 
Cc: Balbir Singh 
Cc: Dr. Thomas Orgis 
Cc: Fan Yu 
Cc: Wang Yaxin 
Cc: 
Signed-off-by: Andrew Morton

fdget(), more trivial conversions

2024-11-03T06:28:06+00:00

all failure exits prior to fdget() leave the scope, all matching fdput()
are immediately followed by leaving the scope.

[xfs_ioc_commit_range() chunk moved here as well]

Reviewed-by: Christian Brauner 
Signed-off-by: Al Viro

introduce fd_file(), convert all accessors to it.

2024-08-13T02:00:43+00:00

	For any changes of struct fd representation we need to
turn existing accesses to fields into calls of wrappers.
Accesses to struct fd::flags are very few (3 in linux/file.h,
1 in net/socket.c, 3 in fs/overlayfs/file.c and 3 more in
explicit initializers).
	Those can be dealt with in the commit converting to
new layout; accesses to struct fd::file are too many for that.
	This commit converts (almost) all of f.file to
fd_file(f).  It's not entirely mechanical ('file' is used as
a member name more than just in struct fd) and it does not
even attempt to distinguish the uses in pointer context from
those in boolean context; the latter will be eventually turned
into a separate helper (fd_empty()).

	NOTE: mass conversion to fd_empty(), tempting as it
might be, is a bad idea; better do that piecewise in commit
that convert from fdget...() to CLASS(...).

[conflicts in fs/fhandle.c, kernel/bpf/syscall.c, mm/memcontrol.c
caught by git; fs/stat.c one got caught by git grep]
[fs/xattr.c conflict]

Reviewed-by: Christian Brauner 
Signed-off-by: Al Viro

taskstats: fill_stats_for_tgid: use for_each_thread()

2023-10-04T17:41:57+00:00

do/while_each_thread should be avoided when possible.

Plus I _think_ this change allows to avoid lock_task_sighand() but I am
not sure, I forgot everything about taskstats.  In any case, this code
does not look right in that the same thread can be accounted twice:
taskstats_exit() can account the exiting thread in signal->stats and drop
->siglock but this thread is still on the thread-group list, so
lock_task_sighand() can't help.

Link: https://lkml.kernel.org/r/20230909214951.GA24274@redhat.com
Signed-off-by: Oleg Nesterov 
Cc: Eric W. Biederman 
Signed-off-by: Andrew Morton

genetlink: start to validate reserved header bytes

2022-08-29T11:47:15+00:00

We had historically not checked that genlmsghdr.reserved
is 0 on input which prevents us from using those precious
bytes in the future.

One use case would be to extend the cmd field, which is
currently just 8 bits wide and 256 is not a lot of commands
for some core families.

To make sure that new families do the right thing by default
put the onus of opting out of validation on existing families.

Signed-off-by: Jakub Kicinski 
Acked-by: Paul Moore  (NetLabel)
Signed-off-by: David S. Miller