On Fri, Oct 09, 2020 at 11:25:59AM +0200, Peter Zijlstra wrote: > On Fri, Oct 09, 2020 at 10:13:12AM +0200, Morten Rasmussen wrote: > > On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote: > > > > Fundamentally, you're not supposed to change the userspace provided > > > affinity mask. If we want to do something like this, we'll have to teach > > > the scheduler about this second mask such that it can compute an > > > effective mask as the intersection between the 'feature' and user mask. > > > > I agree that we shouldn't mess wit the user-space mask directly. Would it > > be unthinkable to go down the route of maintaining a new mask which is > > the intersection of the feature mask (controlled and updated by arch > > code) and the user-space mask? > > > > It shouldn't add overhead in the scheduler as it would use the > > intersection mask instead of the user-space mask, the main complexity > > would be around making sure the intersection mask is updated correctly > > (cpusets, hotplug, ...). > > IFF we _need_ to go there, then yes that was the plan, compose the > intersection when either the (arch) feature(set) mask or the userspace > mask changes. Another thought: should the arm64 compat_elf_check_arch() and sys_arm64_personality(PER_LINUX32) validate the user cpumask before returning success/failure? It won't prevent the user from changing the affinity at run-time but at least it won't randomly get killed just because the kernel advertises 32-bit support. -- Catalin
