On Thu, Nov 19, 2020 at 02:30:12PM +0000, Quentin Perret wrote: > On Thursday 19 Nov 2020 at 11:07:24 (+0000), Will Deacon wrote: > > Yeah, the cpuset code ignores the return value of set_cpus_allowed_ptr() in > > update_tasks_cpumask() so the failure won't be propagated, but then again I > > think that might be the right thing to do. Nothing prevents 32-bit and > > 64-bit tasks from co-existing in the same cpuseti afaict, so forcing the > > 64-bit tasks onto the 32-bit-capable cores feels much worse than the > > approach taken here imo. > > Ack. And thinking about it more, failing the cgroup operation wouldn't > guarantee that the task's affinity and the cpuset are aligned anyway. We > could still exec into a 32 bit task from within a 64 bit-only cpuset. > > > The interesting case is what happens if the cpuset for a 32-bit task is > > changed to contain only the 64-bit-only cores. I think that's a userspace > > bug > > Maybe, but I think Android will do exactly that in some cases :/ > > > but the fallback rq selection should avert disaster. > > I thought _this_ patch was 'fixing' this case by making the cpuset > operation pretty much a nop on the task affinity? The fallback rq stuff > is all about hotplug no? Yeah, sorry, I wasn't clear. This patch postpones disaster until hotplug off time, when cpuset_cpus_allowed_fallback() will fail and select_fallback_rq() will have to step in. Will
