linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Qais Yousef <qais.yousef@arm.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Quentin Perret <qperret@google.com>, Tejun Heo <tj@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	kernel-team@android.com
Subject: Re: [PATCH v10 13/16] arm64: Advertise CPUs capable of running 32-bit applications in sysfs
Date: Fri, 25 Jun 2021 10:46:35 +0200	[thread overview]
Message-ID: <YNWX64TIVkGyNsbs@kroah.com> (raw)
In-Reply-To: <20210623173848.318-14-will@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 <gregkh@linuxfoundation.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  .../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 <linux-arm-kernel@lists.infradead.org>
> +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 <linux-kernel@vger.kernel.org>
> 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 <linux/crash_dump.h>
>  #include <linux/sort.h>
>  #include <linux/stop_machine.h>
> +#include <linux/sysfs.h>
>  #include <linux/types.h>
>  #include <linux/minmax.h>
>  #include <linux/mm.h>
> @@ -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

  reply	other threads:[~2021-06-25  8:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 17:38 [PATCH v10 00/16] Add support for 32-bit tasks on asymmetric AArch32 systems Will Deacon
2021-06-23 17:38 ` [PATCH v10 01/16] sched: Introduce task_cpu_possible_mask() to limit fallback rq selection Will Deacon
2021-06-23 17:38 ` [PATCH v10 02/16] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Will Deacon
2021-06-23 17:38 ` [PATCH v10 03/16] cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus() Will Deacon
2021-06-23 17:38 ` [PATCH v10 04/16] cpuset: Cleanup cpuset_cpus_allowed_fallback() use in select_fallback_rq() Will Deacon
2021-06-23 17:38 ` [PATCH v10 05/16] sched: Reject CPU affinity changes based on task_cpu_possible_mask() Will Deacon
2021-06-23 17:38 ` [PATCH v10 06/16] sched: Introduce task_struct::user_cpus_ptr to track requested affinity Will Deacon
2021-06-23 17:38 ` [PATCH v10 07/16] sched: Split the guts of sched_setaffinity() into a helper function Will Deacon
2021-06-23 17:38 ` [PATCH v10 08/16] sched: Allow task CPU affinity to be restricted on asymmetric systems Will Deacon
2021-06-23 17:38 ` [PATCH v10 09/16] sched: Introduce dl_task_check_affinity() to check proposed affinity Will Deacon
2021-06-23 17:38 ` [PATCH v10 10/16] arm64: Implement task_cpu_possible_mask() Will Deacon
2021-06-23 17:38 ` [PATCH v10 11/16] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 Will Deacon
2021-06-23 17:38 ` [PATCH v10 12/16] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system Will Deacon
2021-06-23 17:38 ` [PATCH v10 13/16] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon
2021-06-25  8:46   ` Greg Kroah-Hartman [this message]
2021-06-25  9:36     ` Will Deacon
2021-06-25  9:49       ` Greg Kroah-Hartman
2021-06-23 17:38 ` [PATCH v10 14/16] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon
2021-06-23 17:38 ` [PATCH v10 15/16] arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores Will Deacon
2021-06-23 17:38 ` [PATCH v10 16/16] Documentation: arm64: describe asymmetric 32-bit support Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YNWX64TIVkGyNsbs@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bristot@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=rjw@rjwysocki.net \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).