All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	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>,
	kernel-team@android.com
Subject: Re: [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs
Date: Tue, 10 Nov 2020 09:28:43 +0000	[thread overview]
Message-ID: <X6pdSx84CWvag02r@trantor> (raw)
In-Reply-To: <X6o7euVw0QlysIPV@kroah.com>

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 <will@kernel.org>
> > ---
> >  .../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.

The only sane thing is not to allow 32-bit processes at all on such
hardware but I think we lost that battle ;).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arch@vger.kernel.org, kernel-team@android.com,
	Quentin Perret <qperret@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Marc Zyngier <maz@kernel.org>, Qais Yousef <qais.yousef@arm.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Will Deacon <will@kernel.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs
Date: Tue, 10 Nov 2020 09:28:43 +0000	[thread overview]
Message-ID: <X6pdSx84CWvag02r@trantor> (raw)
In-Reply-To: <X6o7euVw0QlysIPV@kroah.com>

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 <will@kernel.org>
> > ---
> >  .../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.

The only sane thing is not to allow 32-bit processes at all on such
hardware but I think we lost that battle ;).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-10  9:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 21:30 [PATCH v2 0/6] An alternative series for asymmetric AArch32 systems Will Deacon
2020-11-09 21:30 ` Will Deacon
2020-11-09 21:30 ` [PATCH v2 1/6] arm64: cpuinfo: Split AArch32 registers out into a separate struct Will Deacon
2020-11-09 21:30   ` Will Deacon
2020-11-09 21:30 ` [PATCH v2 2/6] arm64: Allow mismatched 32-bit EL0 support Will Deacon
2020-11-09 21:30   ` Will Deacon
2020-11-11 19:10   ` Catalin Marinas
2020-11-11 19:10     ` Catalin Marinas
2020-11-13  9:36     ` Will Deacon
2020-11-13  9:36       ` Will Deacon
2020-11-13 10:26       ` Catalin Marinas
2020-11-13 10:26         ` Catalin Marinas
2020-11-09 21:30 ` [PATCH v2 3/6] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched " Will Deacon
2020-11-09 21:30   ` Will Deacon
2020-11-10  9:33   ` Marc Zyngier
2020-11-10  9:33     ` Marc Zyngier
2020-11-09 21:30 ` [PATCH v2 4/6] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Will Deacon
2020-11-09 21:30   ` Will Deacon
2020-11-09 21:30 ` [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon
2020-11-09 21:30   ` Will Deacon
2020-11-10  7:04   ` Greg Kroah-Hartman
2020-11-10  7:04     ` Greg Kroah-Hartman
2020-11-10  9:28     ` Catalin Marinas [this message]
2020-11-10  9:28       ` Catalin Marinas
2020-11-10  9:36       ` Greg Kroah-Hartman
2020-11-10  9:36         ` Greg Kroah-Hartman
2020-11-10  9:53         ` Marc Zyngier
2020-11-10  9:53           ` Marc Zyngier
2020-11-10 10:10           ` Greg Kroah-Hartman
2020-11-10 10:10             ` Greg Kroah-Hartman
2020-11-10 10:46             ` Marc Zyngier
2020-11-10 10:46               ` Marc Zyngier
2020-11-10 10:57         ` Catalin Marinas
2020-11-10 10:57           ` Catalin Marinas
2020-11-09 21:30 ` [PATCH v2 6/6] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon
2020-11-09 21:30   ` 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=X6pdSx84CWvag02r@trantor \
    --to=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=surenb@google.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.