On Thu, Oct 08, 2020 at 07:16:41PM +0100, Qais Yousef wrote:
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index cf94cc248fbe..7e97f1589f33 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -908,13 +908,28 @@ static void do_signal(struct pt_regs *regs)
> restore_saved_sigmask();
> }
>
> +static void set_32bit_cpus_allowed(void)
> {
> + cpumask_var_t cpus_allowed;
> + int ret = 0;
> +
> + if (cpumask_subset(current->cpus_ptr, &aarch32_el0_mask))
> + return;
> +
> /*
> + * On asym aarch32 systems, if the task has invalid cpus in its mask,
> + * we try to fix it by removing the invalid ones.
> */
> + if (!alloc_cpumask_var(&cpus_allowed, GFP_ATOMIC)) {
> + ret = -ENOMEM;
> + } else {
> + cpumask_and(cpus_allowed, current->cpus_ptr, &aarch32_el0_mask);
> + ret = set_cpus_allowed_ptr(current, cpus_allowed);
> + free_cpumask_var(cpus_allowed);
> + }
> +
> + if (ret) {
> + pr_warn_once("Failed to fixup affinity of running 32-bit task\n");
> force_sig(SIGKILL);
> }
> }
Yeah, no. Not going to happen.
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.
Also, practically, using ->cpus_ptr here to construct the mask will be
really dodgy vs the proposed migrate_disable() patches.
