Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp253157pxj; Thu, 3 Jun 2021 06:00:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcFD1hcdUC2anU+KpT4dXDapzCg/fFhn1bhTPHsCnYFo4j5JzltUQin2E5BoywZTZjbppj X-Received: by 2002:a17:906:5210:: with SMTP id g16mr39092311ejm.116.1622725218605; Thu, 03 Jun 2021 06:00:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622725218; cv=none; d=google.com; s=arc-20160816; b=Bi+cl/DFrEmhbKhLrsXPAIDE54IfrgpNmQFDb1LVmO2TerlCd9Jd9ThQQj/nbkztIa 129qsVSehdrpAHp2yveoZgDKWL3d4fHAHG+AZbGtN0fO9ikRJaJQuI3QuNKLEWsR2UW3 EvDaCsOM640Ozu2p1Zc1mzIYvTH2brqWxMvF9+I1e6lsQduB6jWU9Wr0QqmKaNv3ZuHQ OeUnxiA8+a4jlfHcSP62S5rlUQ6hg95mAalkcAYCEIst5vYW7pAlZf9rVKcxjGcCknN0 PMZiY4uCkZQLOfWh6LaN47D5aRYsZaQ+ZedGh5CHcNgKrU1UouwyueXuRCulSZdupsAh RZgA== 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=XPr8Mgnv0+VIE2/UgCmM/n+4ke66LjEUutnhvxHbBeA=; b=t5EhvLzAysp/8/Jyfr4R1v88fSL6KnfIWjlHhsUCDPxN/MBkUL2lsbrWGHVEXb7Pla xJ7a7pSE6kJDr3gKVbVS/c9WpCksrqyw3leuuzwRHK0E/Z+wP9hcoHqZ5cih5Yi5CLRz JnmOom/gzjerg8a28OssNetsBuSwZPe5vBn8Jbnnt4b2c9BAaD1aWpb4xT8hkDp5TfDT Rm3gZtz4zI2EI3000FDV5w+vKwiYnZqpc3ANbk4O3tsHIotVhembu5hl8lJqVPsy665E VKmv0KEBO080A6/t1ez1miyKCXfnaC3JfrmVFlWR06OMxCDw3k+6YtAOJmJzaewGPXFO 4jSw== 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 v5si18362ejv.666.2021.06.03.05.59.55; Thu, 03 Jun 2021 06:00:18 -0700 (PDT) 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 S230370AbhFCNAt (ORCPT + 99 others); Thu, 3 Jun 2021 09:00:49 -0400 Received: from foss.arm.com ([217.140.110.172]:40942 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229950AbhFCNAs (ORCPT ); Thu, 3 Jun 2021 09:00:48 -0400 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 B34BC1063; Thu, 3 Jun 2021 05:59:03 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.3.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4929C3F774; Thu, 3 Jun 2021 05:58:59 -0700 (PDT) Date: Thu, 3 Jun 2021 13:58:56 +0100 From: Mark Rutland 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 , Qais Yousef , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Dietmar Eggemann , Daniel Bristot de Oliveira , Valentin Schneider , kernel-team@android.com Subject: Re: [PATCH v8 15/19] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system Message-ID: <20210603125856.GC48596@C02TD0UTHF1T.local> References: <20210602164719.31777-1-will@kernel.org> <20210602164719.31777-16-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210602164719.31777-16-will@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 02, 2021 at 05:47:15PM +0100, Will Deacon wrote: > If we want to support 32-bit applications, then when we identify a CPU > with mismatched 32-bit EL0 support we must ensure that we will always > have an active 32-bit CPU available to us from then on. This is important > for the scheduler, because is_cpu_allowed() will be constrained to 32-bit > CPUs for compat tasks and forced migration due to a hotplug event will > hang if no 32-bit CPUs are available. > > On detecting a mismatch, prevent offlining of either the mismatching CPU > if it is 32-bit capable, or find the first active 32-bit capable CPU > otherwise. > > Reviewed-by: Catalin Marinas > Signed-off-by: Will Deacon > --- > arch/arm64/kernel/cpufeature.c | 20 +++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 4194a47de62d..b31d7a1eaed6 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2877,15 +2877,33 @@ void __init setup_cpu_features(void) > > static int enable_mismatched_32bit_el0(unsigned int cpu) > { > + static int lucky_winner = -1; This is cute, but could we please give it a meaningful name, e.g. `pinned_cpu` ? > + > struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu); > bool cpu_32bit = id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0); > > if (cpu_32bit) { > cpumask_set_cpu(cpu, cpu_32bit_el0_mask); > static_branch_enable_cpuslocked(&arm64_mismatched_32bit_el0); > - setup_elf_hwcaps(compat_elf_hwcaps); > } > > + if (cpumask_test_cpu(0, cpu_32bit_el0_mask) == cpu_32bit) > + return 0; > + > + if (lucky_winner >= 0) > + return 0; > + > + /* > + * We've detected a mismatch. We need to keep one of our CPUs with > + * 32-bit EL0 online so that is_cpu_allowed() doesn't end up rejecting > + * every CPU in the system for a 32-bit task. > + */ > + lucky_winner = cpu_32bit ? cpu : cpumask_any_and(cpu_32bit_el0_mask, > + cpu_active_mask); > + get_cpu_device(lucky_winner)->offline_disabled = true; > + setup_elf_hwcaps(compat_elf_hwcaps); > + pr_info("Asymmetric 32-bit EL0 support detected on CPU %u; CPU hot-unplug disabled on CPU %u\n", > + cpu, lucky_winner); > return 0; > } I guess this is going to play havoc with kexec and hibernate. :/ Thanks, Mark.