From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B845DC388F7 for ; Tue, 10 Nov 2020 10:57:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B8E7207BB for ; Tue, 10 Nov 2020 10:57:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726428AbgKJK5I (ORCPT ); Tue, 10 Nov 2020 05:57:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:55244 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726280AbgKJK5I (ORCPT ); Tue, 10 Nov 2020 05:57:08 -0500 Received: from trantor (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 085F3206F1; Tue, 10 Nov 2020 10:57:04 +0000 (UTC) Date: Tue, 10 Nov 2020 10:57:02 +0000 From: Catalin Marinas To: Greg Kroah-Hartman Cc: Will Deacon , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Marc Zyngier , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Quentin Perret , kernel-team@android.com Subject: Re: [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Message-ID: References: <20201109213023.15092-1-will@kernel.org> <20201109213023.15092-6-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Tue, Nov 10, 2020 at 10:36:33AM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 10, 2020 at 09:28:43AM +0000, Catalin Marinas wrote: > > On Tue, Nov 10, 2020 at 08:04:26AM +0100, Greg Kroah-Hartman wrote: > > > On Mon, Nov 09, 2020 at 09:30:21PM +0000, Will Deacon wrote: > > > > Since 32-bit applications will be killed if they are caught trying to > > > > execute on a 64-bit-only CPU in a mismatched system, advertise the set > > > > of 32-bit capable CPUs to userspace in sysfs. > > > > > > > > Signed-off-by: Will Deacon > > > > --- > > > > .../ABI/testing/sysfs-devices-system-cpu | 9 +++++++++ > > > > arch/arm64/kernel/cpufeature.c | 19 +++++++++++++++++++ > > > > 2 files changed, 28 insertions(+) > > > > > > I still think the "kill processes that can not run on this CPU" is crazy > > > > I agree it's crazy, though we try to keep the kernel support simple > > while making it a user-space problem. The alternative is to > > force-migrate such process to a more capable CPU, potentially against > > the desired user cpumask. In addition, we'd have to block CPU hot-unplug > > in case the last 32-bit capable CPU disappears. > > You should block CPU hot-unplug for the last 32bit capable CPU, why > would you not want that if there are any active 32bit processes running? That's been done in one of the versions submitted to the Android kernel (which also handles automatic task placement, though by overriding the user cpumask): https://android-review.googlesource.com/c/kernel/common/+/1437100/7 I think preventing CPU offlining makes sense only together with forcing 32-bit task placement from the kernel. If we decide to go for the SIGKILL approach with user-driven affinity, careful CPU offlining should also be handled by user-space. -- Catalin