From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Catalin Marinas <catalin.marinas@arm.com> 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 10:36:33 +0100 [thread overview] Message-ID: <X6pfISu1PE5lelNL@kroah.com> (raw) In-Reply-To: <X6pdSx84CWvag02r@trantor> 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 <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. 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
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Catalin Marinas <catalin.marinas@arm.com> 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 10:36:33 +0100 [thread overview] Message-ID: <X6pfISu1PE5lelNL@kroah.com> (raw) In-Reply-To: <X6pdSx84CWvag02r@trantor> 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 <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. 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
next prev parent reply other threads:[~2020-11-10 9:35 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 2020-11-10 9:28 ` Catalin Marinas 2020-11-10 9:36 ` Greg Kroah-Hartman [this message] 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=X6pfISu1PE5lelNL@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=catalin.marinas@arm.com \ --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: linkBe 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.