TASKSTATS_CMD_ATTR_REGISTER_CPUMASK broken in recent kernels

[Mattias RÃnnblom]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/