CVE-2022-50103: sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed

In the Linux kernel, the following vulnerability has been resolved:

sched, cpuset: Fix dlcpubusy() panic due to empty cs->cpusallowed

With cgroup v2, the cpuset's cpusallowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpusetcanattach() can call taskcanattach() with an empty mask. This can lead to cpumaskanyand() returns nrcpuids causing the call to dlbwof() to crash due to percpu value access of an out of bound CPU value. For example:

[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dlcpubusy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpusetcanattach+0xa0/0x140 [80468.209953] cgroupmigrateexecute+0x8c/0x490 [80468.210931] cgroupupdatedflcsses+0x254/0x270 [80468.211898] cgroupsubtreecontrolwrite+0x322/0x400 [80468.212854] kernfsfopwriteiter+0x11c/0x1b0 [80468.213777] newsyncwrite+0x11f/0x1b0 [80468.214689] vfswrite+0x1eb/0x280 [80468.215592] ksyswrite+0x5f/0xe0 [80468.216463] dosyscall64+0x5c/0x80 [80468.224287] entrySYSCALL64afterhwframe+0x44/0xae

Fix that by using effectivecpus instead. For cgroup v1, effectivecpus is the same as cpusallowed. For v2, effectivecpus is the real cpumask to be used by tasks within the cpuset anyway.

Also update taskcanattach()'s 2nd argument name to cseffectivecpus to reflect the change. In addition, a check is added to taskcanattach() to guard against the possibility that cpumaskanyand() may return a value >= nrcpuids.