sched/core: Don't return -ENODEV from sched_setaffinity()

JIRA: https://issues.redhat.com/browse/RHEL-16613
MR: !3388 (merged)
Upstream Status: RHEL only
Tested: A unit test was run to verify that CPU affinity reset only happened when the full mask was empty not when any of the out of bound bits were set.

RHEL commit 05fddaaa ("sched/core: Use empty mask to reset cpumasks in sched_setaffinity()") enables the use of an empty cpumask to reset a user-provided CPU affinity via sched_setaffinity(2) syscall. It will return a value of -ENODEV to indicate a success in resetting the user provided CPU affinity.

However, the current way to check for empty cpumask using cpumask_emtpy() is not robust enough to avoid many false positives leading to an erroneous return of -ENODEV which can confuse user applications leading to incorrect behavior. For example, if the system has 28 CPUs and bit 28 is set, it will treat the cpumask as empty.

Instead of cpumask_empty(), bitmap_empty() should be used to check if all the bits in the cpumask_size() buffer are zero. This should avoid many false positives. However, false positive can still happen if the bit set is outside the range allowed by cpumask_size(). So we need to check the full user_mask buffer to see if it is really empty to avoid any false positive. By doing so, there should be no need to return a -ENODEV error code which is a workaround to handle the false positives. A value of 0 will be returned if the reset is successful or -EINVAL will be if user-provided CPU affinity hasn't been properly set by sched_setaffinity(2).

Fixes: 05fddaaa ("sched/core: Use empty mask to reset cpumasks in sched_setaffinity()") Signed-off-by: Waiman Long longman@redhat.com