[RFC PATCH 0/2] cpuset: Skip possible unwanted CPU-mask updates.

[Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>]

Hi,

while playing with cgroups and tasks which alter their CPU-mask I
noticed a behaviour which is unwanted:
- Upon enabling the cpuset controller, all currently set CPU-mask are
  changed. Here one could argue how bad it is assuming that the
  controller gets only enabled once during boot.

- While having a task limited to only one CPU (or more but a subset of
  the cpuset's mask) then adding an additional CPU (or removing an
  unrelated CPU) from that cpuset results in changing the CPU-mask of
  that task and adding additional CPUs.

The test used to verify the behaviour:

# Limit to CPU 0-1
$ taskset -pc 0-1 $$
# Enable the cpuset controller
$  echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control ; echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

# Query the CPU-mask. Expect to see 0-1 since it is a subset of
# all-online-CPUs
$ taskset -pc $$

# Update the mask to CPUs 1-2
$ taskset -pc 1-2 $$

# Change the CPU-mask of the cgroup to CPUs 1-3.
$ echo 1-3 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 1-2 because it is a subset of 1-3
$ taskset -pc $$

# Change the CPU-mask of the cgroup to CPUs 2-3.
$ echo 2-3 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 2-3 because CPU 1 is not part of 2-3
$ taskset -pc $$

# Change the CPU-mask of the cgroup to CPUs 2-4.
$ echo 2-4 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 2-4 because task's old CPU-mask matches the old mask of
# the cpuset.
$ taskset -pc $$

Posting this as RFC in case I'm missing something obvious or breaking an
unknown (to me) requirement that this series would break.

Sebastian