All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea della Porta <aporta@suse.de>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrea della Porta <andrea.porta@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, nik.borisov@suse.com
Subject: Re: [PATCH 3/4] arm64/entry-common: Make Aarch32 syscalls' availability depend on aarch32_enabled()
Date: Thu, 19 Oct 2023 14:48:29 +0200	[thread overview]
Message-ID: <ZTElnWpvwcxPsfls@apocalypse> (raw)
In-Reply-To: <ZS_WHHnWzfkKtJWs@FVFF77S0Q05N.cambridge.arm.com>

On 13:57 Wed 18 Oct     , Mark Rutland wrote:
> On Wed, Oct 18, 2023 at 01:13:21PM +0200, Andrea della Porta wrote:
> > Another major aspect of supporting running of 32bit processes is the
> > ability to access 32bit syscalls. Such syscalls can be invoked by
> > using the svc instruction.
> > 
> > If Aarch32 emulation is disabled ensure that calling svc results
> > in the same behavior as if CONFIG_COMPAT has not been enabled (i.e.
> > a kernel panic).
> 
> It's not "emulation" it's directly supported by the hardware.

You're right. I also struggled to use this label but I just reused the same
name from Nikolai's patchset for x86, in the hope that the option would be
more recognizable (something like 'ARCH_emulation' that could be used maybe
for other platforms as well), but I agree with you that this is highly
misleading. I will change it to something more straightforward.

> 
> > 
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> > ---
> >  arch/arm64/kernel/entry-common.c | 25 ++++++++++++++++++++++---
> >  1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 69ff9b8c0bde..32761760d9dd 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -802,6 +802,11 @@ asmlinkage void noinstr el0t_64_error_handler(struct pt_regs *regs)
> >  }
> >  
> >  #ifdef CONFIG_COMPAT
> > +UNHANDLED(el0t, 32, sync_ni)
> > +UNHANDLED(el0t, 32, irq_ni)
> > +UNHANDLED(el0t, 32, fiq_ni)
> > +UNHANDLED(el0t, 32, error_ni)
> 
> IRQ, FIQ, and SError are not syscalls, so the commit title is bad.

Agreed. I'll call them exceptions.

> 
> > +
> >  static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
> >  {
> >  	enter_from_user_mode(regs);
> > @@ -821,6 +826,11 @@ static void noinstr el0_svc_compat(struct pt_regs *regs)
> >  
> >  asmlinkage void noinstr el0t_32_sync_handler(struct pt_regs *regs)
> >  {
> > +	if (!aarch32_enabled()) {
> > +		el0t_32_sync_ni_handler(regs);
> > +		return;
> > +	}
> 
> Why do we have to do this at all?
> 
> If we don't have AArch32 tasks, these paths are unreachable. Why do we need to
> check that they aren't called?
> 
> Mark.

Agreed. Please see also my previous comments here:
https://lore.kernel.org/lkml/ZTEKabxNdegsbxyv@apocalypse/
https://lore.kernel.org/lkml/ZTD0DAes-J-YQ2eu@apocalypse/

but again, that's only speculative as of now, so we can ignore that part.

Andrea

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

WARNING: multiple messages have this Message-ID (diff)
From: Andrea della Porta <aporta@suse.de>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrea della Porta <andrea.porta@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, nik.borisov@suse.com
Subject: Re: [PATCH 3/4] arm64/entry-common: Make Aarch32 syscalls' availability depend on aarch32_enabled()
Date: Thu, 19 Oct 2023 14:48:29 +0200	[thread overview]
Message-ID: <ZTElnWpvwcxPsfls@apocalypse> (raw)
In-Reply-To: <ZS_WHHnWzfkKtJWs@FVFF77S0Q05N.cambridge.arm.com>

On 13:57 Wed 18 Oct     , Mark Rutland wrote:
> On Wed, Oct 18, 2023 at 01:13:21PM +0200, Andrea della Porta wrote:
> > Another major aspect of supporting running of 32bit processes is the
> > ability to access 32bit syscalls. Such syscalls can be invoked by
> > using the svc instruction.
> > 
> > If Aarch32 emulation is disabled ensure that calling svc results
> > in the same behavior as if CONFIG_COMPAT has not been enabled (i.e.
> > a kernel panic).
> 
> It's not "emulation" it's directly supported by the hardware.

You're right. I also struggled to use this label but I just reused the same
name from Nikolai's patchset for x86, in the hope that the option would be
more recognizable (something like 'ARCH_emulation' that could be used maybe
for other platforms as well), but I agree with you that this is highly
misleading. I will change it to something more straightforward.

> 
> > 
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> > ---
> >  arch/arm64/kernel/entry-common.c | 25 ++++++++++++++++++++++---
> >  1 file changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 69ff9b8c0bde..32761760d9dd 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -802,6 +802,11 @@ asmlinkage void noinstr el0t_64_error_handler(struct pt_regs *regs)
> >  }
> >  
> >  #ifdef CONFIG_COMPAT
> > +UNHANDLED(el0t, 32, sync_ni)
> > +UNHANDLED(el0t, 32, irq_ni)
> > +UNHANDLED(el0t, 32, fiq_ni)
> > +UNHANDLED(el0t, 32, error_ni)
> 
> IRQ, FIQ, and SError are not syscalls, so the commit title is bad.

Agreed. I'll call them exceptions.

> 
> > +
> >  static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
> >  {
> >  	enter_from_user_mode(regs);
> > @@ -821,6 +826,11 @@ static void noinstr el0_svc_compat(struct pt_regs *regs)
> >  
> >  asmlinkage void noinstr el0t_32_sync_handler(struct pt_regs *regs)
> >  {
> > +	if (!aarch32_enabled()) {
> > +		el0t_32_sync_ni_handler(regs);
> > +		return;
> > +	}
> 
> Why do we have to do this at all?
> 
> If we don't have AArch32 tasks, these paths are unreachable. Why do we need to
> check that they aren't called?
> 
> Mark.

Agreed. Please see also my previous comments here:
https://lore.kernel.org/lkml/ZTEKabxNdegsbxyv@apocalypse/
https://lore.kernel.org/lkml/ZTD0DAes-J-YQ2eu@apocalypse/

but again, that's only speculative as of now, so we can ignore that part.

Andrea

  reply	other threads:[~2023-10-19 12:49 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 11:13 [PATCH 0/4] arm64: Make Aarch32 compatibility enablement optional at boot Andrea della Porta
2023-10-18 11:13 ` Andrea della Porta
2023-10-18 11:13 ` [PATCH 1/4] arm64: Introduce aarch32_enabled() Andrea della Porta
2023-10-18 11:13   ` Andrea della Porta
2023-10-18 11:13 ` [PATCH 2/4] arm64/process: Make loading of 32bit processes depend on aarch32_enabled() Andrea della Porta
2023-10-18 11:13   ` Andrea della Porta
2023-10-18 12:52   ` Mark Rutland
2023-10-18 12:52     ` Mark Rutland
2023-10-19 12:38     ` Andrea della Porta
2023-10-19 12:38       ` Andrea della Porta
2023-10-19 14:27       ` Mark Rutland
2023-10-19 14:27         ` Mark Rutland
2023-10-19 14:32         ` Andrea della Porta
2023-10-19 14:32           ` Andrea della Porta
2023-10-19 14:50           ` Mark Rutland, Will Deacon
2023-10-19 14:50             ` Mark Rutland, Will Deacon
2023-10-18 11:13 ` [PATCH 3/4] arm64/entry-common: Make Aarch32 syscalls' availability " Andrea della Porta
2023-10-18 11:13   ` Andrea della Porta
2023-10-18 12:57   ` Mark Rutland
2023-10-18 12:57     ` Mark Rutland
2023-10-19 12:48     ` Andrea della Porta [this message]
2023-10-19 12:48       ` Andrea della Porta
2023-10-22 20:30   ` kernel test robot
2023-10-22 20:30     ` kernel test robot
2023-10-18 11:13 ` [PATCH 4/4] arm64: Make Aarch32 emulation boot time configurable Andrea della Porta
2023-10-18 11:13   ` Andrea della Porta
2023-10-18 13:02   ` Mark Rutland
2023-10-18 13:02     ` Mark Rutland
2023-10-19 12:50     ` Andrea della Porta
2023-10-19 12:50       ` Andrea della Porta
2023-10-18 12:27 ` [PATCH 0/4] arm64: Make Aarch32 compatibility enablement optional at boot Will Deacon
2023-10-18 12:27   ` Will Deacon
2023-10-18 12:44   ` Arnd Bergmann
2023-10-18 12:44     ` Arnd Bergmann
2023-10-19 10:52     ` Andrea della Porta
2023-10-19 10:52       ` Andrea della Porta
2023-10-19 11:41       ` Arnd Bergmann
2023-10-19 11:41         ` Arnd Bergmann
2023-10-19  9:17   ` Andrea della Porta
2023-10-19  9:17     ` Andrea della Porta
2023-10-18 12:52 ` Mark Rutland
2023-10-18 12:52   ` Mark Rutland
2023-10-19 12:34   ` Andrea della Porta
2023-10-19 12:34     ` Andrea della Porta

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=ZTElnWpvwcxPsfls@apocalypse \
    --to=aporta@suse.de \
    --cc=andrea.porta@suse.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nik.borisov@suse.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.