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=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 31319C2B9F4 for ; Fri, 25 Jun 2021 08:46:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18AA161427 for ; Fri, 25 Jun 2021 08:46:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230296AbhFYItB (ORCPT ); Fri, 25 Jun 2021 04:49:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:55404 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229839AbhFYIs6 (ORCPT ); Fri, 25 Jun 2021 04:48:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9C89E6141C; Fri, 25 Jun 2021 08:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1624610798; bh=k0YWqkCUy3RGtdCsOBfK8gvBJN3ud9zj7lvL3kFNjAY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VDR5ci+oNRMJ4uzMyayoa0PvasYVgTmfXR2pSWETboH7V7+cS51AASr0Z6aR92gAN MTCp5Vjd4rERsvOesewcd8MV1yCzn/AvJJJpTCuRHy90L1OJRHkBwrL6/BuYj1ivLq ol2b4fBev5kO1MLHZLiBIdcNpQuP8WWv5vbblAdA= Date: Fri, 25 Jun 2021 10:46:35 +0200 From: Greg Kroah-Hartman To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , 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 , Mark Rutland , kernel-team@android.com Subject: Re: [PATCH v10 13/16] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Message-ID: References: <20210623173848.318-1-will@kernel.org> <20210623173848.318-14-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210623173848.318-14-will@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2021 at 06:38:45PM +0100, 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. > > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Catalin Marinas > Signed-off-by: Will Deacon > --- > .../ABI/testing/sysfs-devices-system-cpu | 9 +++++++++ > arch/arm64/kernel/cpufeature.c | 19 +++++++++++++++++++ > 2 files changed, 28 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu > index fe13baa53c59..899377b2715a 100644 > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > @@ -494,6 +494,15 @@ Description: AArch64 CPU registers > 'identification' directory exposes the CPU ID registers for > identifying model and revision of the CPU. > > +What: /sys/devices/system/cpu/aarch32_el0 > +Date: May 2021 > +Contact: Linux ARM Kernel Mailing list > +Description: Identifies the subset of CPUs in the system that can execute > + AArch32 (32-bit ARM) applications. If present, the same format as > + /sys/devices/system/cpu/{offline,online,possible,present} is used. > + If absent, then all or none of the CPUs can execute AArch32 > + applications and execve() will behave accordingly. > + > What: /sys/devices/system/cpu/cpu#/cpu_capacity > Date: December 2016 > Contact: Linux kernel mailing list > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 2f9fe57ead97..23eaa7f06f76 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1319,6 +1320,24 @@ const struct cpumask *system_32bit_el0_cpumask(void) > return cpu_possible_mask; > } > > +static ssize_t aarch32_el0_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + const struct cpumask *mask = system_32bit_el0_cpumask(); > + > + return sysfs_emit(buf, "%*pbl\n", cpumask_pr_args(mask)); > +} > +static const DEVICE_ATTR_RO(aarch32_el0); I just realized that we have a problem with this type of representation overflowing PAGE_SIZE on larger systems. There is ongoing work to fix this up but that requires converting these to binary sysfs files, which is a pain to preserve the original format here. Yes, for now you will be fine on these arm32 systems, but in the future this will have to be changed. Because of that, should you just make this an individual cpu attribute (one file per cpu) and not a single file that lists all cpus? what tool is going to read this and why can't they just pick it up from the individual cpu files instead? thanks, greg k-h