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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 DE733C4741F for ; Tue, 10 Nov 2020 09:37:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6920020780 for ; Tue, 10 Nov 2020 09:37:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="y8g396QS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XIhXIl7l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6920020780 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oJkSoWK6196QY4mDGaj8mskdgnfzkNxdB9eV3RGBoe4=; b=y8g396QSKd/B+Ux+nT5vgO1tp v2EWibHNwyc1KaIsf5U709ZJT6GNPWcOY3bjLx3/JbKIPkyg82U0Vwfc6u5cuCdRl5O4/ICS6PKAI HFeBRLQwsspLOjmr2Vi8gOv3Rfvi7wpMGt4qCJnPPN97GUk1Mdh54DM42xk44fzbyoY/U9a8wbHIL s6G2bfKhrFwRt0eA1IofhurrPofFzX8tkD6/QYVIgisVoo3vpCAfQBQgZgqJxXUt7A45fk1aOR+V5 2AIJybTiPmNEGutU4cUoe5P/4PxVtMXpWabFOidNSTvYQB+GidIYzBGFWriNGx5QSvC1LClWXpfTS PHuCuUD9w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcQ3v-0004xL-NF; Tue, 10 Nov 2020 09:35:39 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcQ3t-0004wO-9c for linux-arm-kernel@lists.infradead.org; Tue, 10 Nov 2020 09:35:38 +0000 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 7327A20780; Tue, 10 Nov 2020 09:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605000936; bh=9MdFHeB2bNIr015cgY11oRfLVJ4BDEFfQ1Nc6iS/ffg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XIhXIl7lGSIWPBFGFivtW+0mpp6v1hrW2h2g8210U7HOR1c1R6kRRBt+3VAjQP0j+ oIcG4XIcjqmgiTOXuHhfp9RWrFpJWmaL55chifFHPjMYGkIZd1PnK+1SLyrGdX5bLg Aa/2nJMGNt/sHZgnK5xgbUeSALPAeOH0x3d687i4= Date: Tue, 10 Nov 2020 10:36:33 +0100 From: Greg Kroah-Hartman To: Catalin Marinas 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201110_043537_444991_B945D1DF X-CRM114-Status: GOOD ( 24.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, kernel-team@android.com, Quentin Perret , Peter Zijlstra , Marc Zyngier , Qais Yousef , Suren Baghdasaryan , Will Deacon , Morten Rasmussen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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? And how is userspace going to know that it is creating a 32bit process? Are you now going to force all calls to exec() to be mediated somehow by putting an ELF parser in the init process? > The only sane thing is not to allow 32-bit processes at all on such > hardware but I think we lost that battle ;). That was a hardware decision that was made for some specific reason, so supporting it in the best way seems to be our best option given that people obviously must want this crazy type of system otherwise they wouldn't be paying for it! While punting the logic out to userspace is simple for the kernel, and of course my first option, I think this isn't going to work in the long-run and the kernel will have to "know" what type of process it is scheduling in order to correctly deal with this nightmare as userspace can't do that well, if at all. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel