All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH v2] powerpc/rtas: Keep MSR[RI] set when calling RTAS
Date: Wed, 04 May 2022 15:59:29 +1000	[thread overview]
Message-ID: <87ee19vnwe.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <c33a2be3-d4b7-9b3b-c980-552f5de081be@linux.ibm.com>

Laurent Dufour <ldufour@linux.ibm.com> writes:
> On 03/05/2022, 17:06:41, Michael Ellerman wrote:
>> Laurent Dufour <ldufour@linux.ibm.com> writes:
...
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index 1f42aabbbab3..d7775b8c8853 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
>>> @@ -49,6 +49,11 @@ void enter_rtas(unsigned long);
>>>  
>>>  static inline void do_enter_rtas(unsigned long args)
>>>  {
>>> +	unsigned long msr;
>>> +
>>> +	msr = mfmsr();
>>> +	BUG_ON(!(msr & MSR_RI));
>> 
>> I'm not sure about this.
>> 
>> We call RTAS in some low-level places, so if we ever hit this BUG_ON
>> then it might cause us to crash badly, or recursively BUG.
>> 
>> A WARN_ON_ONCE() might be safer?
>
> I'm afraid a BUG_ON is required here. Since MSR[RI] is set on RTAS exit so
> if it was not set when calling RTAS, that's a real issue and should
> generate unexpected behaviour.
>
> Do you have places in mind where RTAS could be called with !MSR[RI]?

The main one I can think of is if someone is using
CONFIG_UDBG_RTAS_CONSOLE, then udbg_rtascon_putc() is wired up as
udbg_putc() and that might be called from anywhere, including xmon.

There's also RTAS calls in low-level xics interrupt code, that might get
called during panic/crash.

I don't expect any of those places to be called with MSR[RI] unset, but
I'm worried that if we're already crashing and for some reason MSR[RI]
is unset, then that BUG_ON will just make things worse.

eg. imagine taking a BUG_ON() for every character we try to print as
part of an oops.

Admittedly CONFIG_UDBG_RTAS_CONSOLE is old and probably not used much
anymore, but I'm still a bit paranoid :)

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	stable@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH v2] powerpc/rtas: Keep MSR[RI] set when calling RTAS
Date: Wed, 04 May 2022 15:59:29 +1000	[thread overview]
Message-ID: <87ee19vnwe.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <c33a2be3-d4b7-9b3b-c980-552f5de081be@linux.ibm.com>

Laurent Dufour <ldufour@linux.ibm.com> writes:
> On 03/05/2022, 17:06:41, Michael Ellerman wrote:
>> Laurent Dufour <ldufour@linux.ibm.com> writes:
...
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index 1f42aabbbab3..d7775b8c8853 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
>>> @@ -49,6 +49,11 @@ void enter_rtas(unsigned long);
>>>  
>>>  static inline void do_enter_rtas(unsigned long args)
>>>  {
>>> +	unsigned long msr;
>>> +
>>> +	msr = mfmsr();
>>> +	BUG_ON(!(msr & MSR_RI));
>> 
>> I'm not sure about this.
>> 
>> We call RTAS in some low-level places, so if we ever hit this BUG_ON
>> then it might cause us to crash badly, or recursively BUG.
>> 
>> A WARN_ON_ONCE() might be safer?
>
> I'm afraid a BUG_ON is required here. Since MSR[RI] is set on RTAS exit so
> if it was not set when calling RTAS, that's a real issue and should
> generate unexpected behaviour.
>
> Do you have places in mind where RTAS could be called with !MSR[RI]?

The main one I can think of is if someone is using
CONFIG_UDBG_RTAS_CONSOLE, then udbg_rtascon_putc() is wired up as
udbg_putc() and that might be called from anywhere, including xmon.

There's also RTAS calls in low-level xics interrupt code, that might get
called during panic/crash.

I don't expect any of those places to be called with MSR[RI] unset, but
I'm worried that if we're already crashing and for some reason MSR[RI]
is unset, then that BUG_ON will just make things worse.

eg. imagine taking a BUG_ON() for every character we try to print as
part of an oops.

Admittedly CONFIG_UDBG_RTAS_CONSOLE is old and probably not used much
anymore, but I'm still a bit paranoid :)

cheers

  reply	other threads:[~2022-05-04  6:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-01 14:06 [PATCH v2] powerpc/rtas: Keep MSR[RI] set when calling RTAS Laurent Dufour
2022-04-01 14:06 ` Laurent Dufour
2022-04-13  5:58 ` Nicholas Piggin
2022-04-13  5:58   ` Nicholas Piggin
2022-04-21 14:09   ` Laurent Dufour
2022-05-03 15:06 ` Michael Ellerman
2022-05-03 15:06   ` Michael Ellerman
2022-05-03 16:16   ` Fabiano Rosas
2022-05-03 16:47     ` Laurent Dufour
2022-05-04  4:27       ` Michael Ellerman
2022-05-04  4:26     ` Michael Ellerman
2022-05-03 16:23   ` Laurent Dufour
2022-05-03 16:23     ` Laurent Dufour
2022-05-04  5:59     ` Michael Ellerman [this message]
2022-05-04  5:59       ` Michael Ellerman
2022-05-04 11:01       ` Laurent Dufour
2022-05-04 11:01         ` Laurent Dufour

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=87ee19vnwe.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=ldufour@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=stable@vger.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.