Messages in this thread | | | From | Mattias Rönnblom <> | Subject | TASKSTATS_CMD_ATTR_REGISTER_CPUMASK broken in recent kernels | Date | Thu, 26 Nov 2015 17:23:51 +0100 |
| |
Hi.
I've noticed that using taskstats and TASKSTATS_CMD_ATTR_REGISTER_CPUMASK doesn't work on my x86_64 system with the stock Ubuntu 15.10 kernel 4.2. It displays the same behaviour with mainline 4.0 and 4.2 (Ubuntu config). CONFIG_CPUMASK_OFFSTACK is not set. This can be reproduced with the getdelays.c sample program found in the Documentation directory. In kernel 3.9, TASKSTATS_CMD_ATTR_REGISTER_CPUMASK works (although from what I can tell, this is by accident only and may vary across different systems).
matro@isengard:~/src/c$ sudo ./getdelays -m 0-1 -l cpumask 0-1 maskset 1 listen forever fatal reply error, errno -22 Sent deregister mask, retval 0 matro@isengard:~/src/c$
The netlink message returned signals EINVAL.
Looking at the kernel code, it's taskstats.c:add_del_listener that doens't accept seemingly valid cpu ranges (valid, as in cpu_possible_mask, is 0-15). cpumask_subset() returns false.
taskstat.c:cmd_attr_register_cpumask (and the deregister-function), which are the two users of add_del_listener(), use a stack-allocated struct cpumask, and parses the user-supplied range string by means of cpulist_parse(). This function delegates to bitmap_parselist() using a bit set length of nr_cpu_ids bits (16, in my case).
In bitmap_parselist the uninitialized cpuset is indeed cleared, but only up to nr_cpu_ids bits (16).
cpumask_subset(), used by add_del_listener() to validate user input, uses cpumask_bits (=NR_CPUS, 256 in my case) of the bit set, erroneously returns false because uninitialized parts of the bitset is taken into account.
You either need to replace alloc_cpumask_var() with zalloc_cpumask_var() in taskstat.c:cmd_attr_register_cpumask (and the deregister function) or limit cpumask_subset() to nr_cpu_ids bits for this to work, from what I can tell.
zalloc_cpumask_var() make the getdelay program work again.
I must say this is all a fairly complex machinery for a seemingly simple function.
I had a brief look at 4.4 RC2, and judging from the code, the problem is still there.
Regards, Mattias
| |