Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1345921pxu; Fri, 27 Nov 2020 05:25:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJzRS6W3U8cvaeL1hW4dRCaTNbBo93HC6QlRjLOP+cA+Ibjvtn2H1MR+kRkgheaTA9BuQSko X-Received: by 2002:a05:6402:3d9:: with SMTP id t25mr7567562edw.338.1606483557905; Fri, 27 Nov 2020 05:25:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606483557; cv=none; d=google.com; s=arc-20160816; b=YybEyNkZ2Twev9AswZjVDMv8akT7FrJqpo57yjgOzPcPxx4Nu+SGVAlZKwUzCjhFs+ cbjntNJ6gLgS8CN87CQPSqT6uii2AbOUh4FzVOVO2unHRBByIiHhea2vtqgURlrTjYhW e3LC2dEHPKs/uBqoo3oXJ6kfT/spyqzTdaFi2Fh1Ms1BhYymtPX4apo161U4UOOSnqlM XW3ZXpHh9Ntv62ga76iTw/QnwjHAYg+TPN2qc+RoDCwMxoBqdDRONA2PNo3AughGLChB vg42MWWD6HwMgmEKASg3QxNQ+zYxcEpg/hrYnq/vadv7Bk9A3+D1g1Gu7EDyLpgCQ1hl /D3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=H+YWHHxyvDVNqWNnpeRK8oEOQF7QjjgIjOwqhe+tZ80=; b=p6ypnHMqDUDJaP8oDt2Or3joE82rDboJH5DqU9U32flBgz03qezTHKTnPKJTkXPt9T y1hg1cuYeYj7+Fkf3MPoDkbo/+wsCkBOkm2S1cZfT1zqvCwRpaNKDD/h3j7gFI0AjWIJ s2xgGISIuBh4c3YMVDKiuGMNXz4IcojSJhuLHciGRXgdxd0hL7jkOLuvrXmTqLLnkKKD 5ze6+0BZxFaJnXc8uk4D+MwLxQBFe60aLEd4+W5lwG4GVSkM/wQTMTJmv7UvNow2pN+h nzZEcJqYIXsL+Rb4BfmrwCiS+mZSDz1OHY0yoMVnS9fH82fKG/+ts/Fw7E6pSjiFb8rn 8YHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t14si3105039edy.67.2020.11.27.05.25.34; Fri, 27 Nov 2020 05:25:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730379AbgK0NXM (ORCPT + 99 others); Fri, 27 Nov 2020 08:23:12 -0500 Received: from foss.arm.com ([217.140.110.172]:41614 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729888AbgK0NXL (ORCPT ); Fri, 27 Nov 2020 08:23:11 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2093731B; Fri, 27 Nov 2020 05:23:11 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (unknown [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E4DAC3F70D; Fri, 27 Nov 2020 05:23:08 -0800 (PST) Date: Fri, 27 Nov 2020 13:23:06 +0000 From: Qais Yousef To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Li Zefan , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , kernel-team@android.com Subject: Re: [PATCH v4 08/14] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 Message-ID: <20201127132306.ee4frq6ujz3fqxic@e107158-lin.cambridge.arm.com> References: <20201124155039.13804-1-will@kernel.org> <20201124155039.13804-9-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201124155039.13804-9-will@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/24/20 15:50, Will Deacon wrote: > When exec'ing a 32-bit task on a system with mismatched support for > 32-bit EL0, try to ensure that it starts life on a CPU that can actually > run it. > > Signed-off-by: Will Deacon > --- > arch/arm64/kernel/process.c | 42 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 1540ab0fbf23..72116b0c7c73 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -625,6 +626,45 @@ unsigned long arch_align_stack(unsigned long sp) > return sp & ~0xf; > } > > +static void adjust_compat_task_affinity(struct task_struct *p) > +{ > + cpumask_var_t cpuset_mask; > + const struct cpumask *possible_mask = system_32bit_el0_cpumask(); > + const struct cpumask *newmask = possible_mask; > + > + /* > + * Restrict the CPU affinity mask for a 32-bit task so that it contains > + * only the 32-bit-capable subset of its original CPU mask. If this is > + * empty, then try again with the cpuset allowed mask. If that fails, > + * forcefully override it with the set of all 32-bit-capable CPUs that > + * we know about. > + * > + * From the perspective of the task, this looks similar to what would > + * happen if the 64-bit-only CPUs were hot-unplugged at the point of > + * execve(). > + */ > + if (!restrict_cpus_allowed_ptr(p, possible_mask)) > + goto out; > + > + if (alloc_cpumask_var(&cpuset_mask, GFP_KERNEL)) { > + cpuset_cpus_allowed(p, cpuset_mask); > + if (cpumask_and(cpuset_mask, cpuset_mask, possible_mask)) { > + newmask = cpuset_mask; > + goto out_set_mask; > + } > + } Wouldn't it be better to move this logic to restrict_cpus_allowed_ptr()? I think it should always take cpusets into account and it's not special to this particular handling here, no? > + > + if (printk_ratelimit()) { > + printk_deferred("Overriding affinity for 32-bit process %d (%s) to CPUs %*pbl\n", > + task_pid_nr(p), p->comm, cpumask_pr_args(newmask)); > + } We have 2 cases where the affinity could have been overridden but we won't print anything: 1. restrict_cpus_allowed_ptr() 2. intersection of cpuset_mask and possible mask drops some cpus. Shouldn't we print something in these cases too? IMO it would be better to move this print to restrict_cpus_allowed_ptr() too. Thanks -- Qais Yousef > +out_set_mask: > + set_cpus_allowed_ptr(p, newmask); > + free_cpumask_var(cpuset_mask); > +out: > + set_tsk_thread_flag(current, TIF_NOTIFY_RESUME); > +} > + > /* > * Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY. > */ > @@ -635,7 +675,7 @@ void arch_setup_new_exec(void) > if (is_compat_task()) { > mmflags = MMCF_AARCH32; > if (static_branch_unlikely(&arm64_mismatched_32bit_el0)) > - set_tsk_thread_flag(current, TIF_NOTIFY_RESUME); > + adjust_compat_task_affinity(current); > } > > current->mm->context.flags = mmflags; > -- > 2.29.2.454.gaff20da3a2-goog >