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=ham 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 0F6FBC48BC2 for ; Fri, 25 Jun 2021 08:46:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EAB0661429 for ; Fri, 25 Jun 2021 08:46:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230251AbhFYIs7 (ORCPT ); Fri, 25 Jun 2021 04:48:59 -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-arch@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 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=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 909A7C2B9F4 for ; Fri, 25 Jun 2021 09:53:39 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 49944613EF for ; Fri, 25 Jun 2021 09:53:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 49944613EF 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=oeHdtn44KT/frASsCkKQB91q2coTy+CSHXlZaScQvXg=; b=P38hr9p35+v3GQ nMu6zLUcMi9abQFChdVCpkgGVDntMgmVeaQiytPbphJEfTyOaPlnJDeDUbqPCg4oC2UDPhkUyuL3H GfoXh4JoMuHWmdF5y6mca+aE1JZ5yKq+q4XhXeAahzWGIpYhU3G8qe8X2e8bvpkR1M8TUwKfaQuOU u5lDLy9rG5lWcJOXUibQv/znlSRUlHq/QwUYeq5k0/pKa0bxp9GJ4MeTrAvL0BSlHWt3axEoEEVF7 M0+A8453WmEU1N5TxuIE1bxxZR2nN1JYPwQtONJKoNZEB0h+u7ItMbJKA12ahO/7MxemiJS+10YEa 3OvE/yai54X3UL/dSunw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwiV3-000maG-3U; Fri, 25 Jun 2021 09:51:49 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwhTy-000Tmc-JO for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 08:46:40 +0000 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-Disposition: inline In-Reply-To: <20210623173848.318-14-will@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210625_014638_723072_2215637D X-CRM114-Status: GOOD ( 22.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel