#5 Increasing the value of CG_VALUE_MAX

[Justin Israel]

CG_VALUE_MAX is arbitrarily set to 100 which limits string values to a max of 100 characters. A potential situation where this will cause a failure is in the case of setting cpuset.cpus to a long list (unrolled/comma-separated) of logical cpu ids.

Example: Passing a list of 64 logical cpu ids as a string

"0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63"

will truncate and result in a badly formatted string value that causes an EOF

"0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36\x01"

This patch increases CG_VALUE_MAX to a value of 1024. While still somewhat arbitrary, it seems this value should cover even the largest case. And since it looks like the string value buffers are being statically allocated per thread, it shouldn't really result in any major impact in initial memory.

[Neil Jones]

I have also encountered this issue on a machine with 72 cores and alternating cpu ids on each NUMA node (even cpus on numa0, odd on numa1). The value gets truncated after a comma and fails validation. Setting CG_VALUE_MAX to a larger value fixes it.

For reference:
The cpuset:
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71

gets truncated to:
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,

This is especially bad because if it were to truncate at the final comma, the error would be invisible to the user.