All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Donnellan <ajd@linux.ibm.com>
To: Nathan Lynch <nathanl@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: tyreld@linux.ibm.com, nnac123@linux.ibm.com,
	ldufour@linux.ibm.com, npiggin@gmail.com
Subject: Re: [PATCH 03/13] powerpc/rtas: avoid device tree lookups in rtas_os_term()
Date: Tue, 22 Nov 2022 14:03:59 +1100	[thread overview]
Message-ID: <2bb6286d131fe34b4358a962f708ee0a9b85e166.camel@linux.ibm.com> (raw)
In-Reply-To: <20221118150751.469393-4-nathanl@linux.ibm.com>

On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas_os_term() is called during panic. Its behavior depends on a
> couple of conditions in the /rtas node of the device tree, the
> traversal of which entails locking and local IRQ state changes. If
> the
> kernel panics while devtree_lock is held, rtas_os_term() as currently
> written could hang.
> 
> Instead of discovering the relevant characteristics at panic time,
> cache them in file-static variables at boot. Note the lookup for
> "ibm,extended-os-term" is converted to of_property_read_bool() since
> it is a boolean property, not a RTAS function token.
> 
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>

This seems sensible, minor comment below.

Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>

> ---
>  arch/powerpc/kernel/rtas.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index c12dd5ed5e00..81e4996012b7 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -947,6 +947,8 @@ void __noreturn rtas_halt(void)
>  
>  /* Must be in the RMO region, so we place it here */
>  static char rtas_os_term_buf[2048];
> +static s32 ibm_os_term_token = RTAS_UNKNOWN_SERVICE;

s32 and int are obviously identical, but rtas_token is declared using
int, as are the other variables where we cache various tokens.

> +static bool ibm_extended_os_term;
>  
>  void rtas_os_term(char *str)
>  {
> @@ -958,14 +960,13 @@ void rtas_os_term(char *str)
>          * this property may terminate the partition which we want to
> avoid
>          * since it interferes with panic_timeout.
>          */
> -       if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
> -           RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-
> term"))
> +       if (ibm_os_term_token == RTAS_UNKNOWN_SERVICE ||
> !ibm_extended_os_term)
>                 return;
>  
>         snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
>  
>         do {
> -               status = rtas_call(rtas_token("ibm,os-term"), 1, 1,
> NULL,
> +               status = rtas_call(ibm_os_term_token, 1, 1, NULL,
>                                    __pa(rtas_os_term_buf));
>         } while (rtas_busy_delay(status));
>  
> @@ -1335,6 +1336,13 @@ void __init rtas_initialize(void)
>         no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry",
> &entry);
>         rtas.entry = no_entry ? rtas.base : entry;
>  
> +       /*
> +        * Discover these now to avoid device tree lookups in the
> +        * panic path.
> +        */
> +       ibm_os_term_token = rtas_token("ibm,os-term");
> +       ibm_extended_os_term = of_property_read_bool(rtas.dev,
> "ibm,extended-os-term");
> +
>         /* If RTAS was found, allocate the RMO buffer for it and look
> for
>          * the stop-self token if any
>          */

-- 
Andrew Donnellan    OzLabs, ADL Canberra
ajd@linux.ibm.com   IBM Australia Limited

  reply	other threads:[~2022-11-22  3:05 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 15:07 [PATCH 00/13] RTAS maintenance Nathan Lynch
2022-11-18 15:07 ` [PATCH 01/13] powerpc/rtas: document rtas_call() Nathan Lynch
2022-11-22  2:46   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 02/13] powerpc/rtasd: use correct OF API for event scan rate Nathan Lynch
2022-11-22  2:39   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 03/13] powerpc/rtas: avoid device tree lookups in rtas_os_term() Nathan Lynch
2022-11-22  3:03   ` Andrew Donnellan [this message]
2022-11-28 18:08     ` Nathan Lynch
2022-11-28  2:29   ` Nicholas Piggin
2022-11-28 18:26     ` Nathan Lynch
2022-11-29  6:45       ` Nicholas Piggin
2022-11-29 15:37         ` Nathan Lynch
2022-11-18 15:07 ` [PATCH 04/13] powerpc/rtas: avoid scheduling " Nathan Lynch
2022-11-22  3:17   ` Andrew Donnellan
2022-11-28  2:34   ` Nicholas Piggin
2022-11-18 15:07 ` [PATCH 05/13] powerpc/pseries/eeh: use correct API for error log size Nathan Lynch
2022-11-22  3:21   ` Andrew Donnellan
2022-11-28 20:22     ` Nathan Lynch
2022-11-18 15:07 ` [PATCH 06/13] powerpc/rtas: clean up rtas_error_log_max initialization Nathan Lynch
2022-11-22  3:40   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 07/13] powerpc/rtas: clean up includes Nathan Lynch
2022-11-22  4:45   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 08/13] powerpc/rtas: define pr_fmt and convert printk call sites Nathan Lynch
2022-11-22  4:07   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 09/13] powerpc/rtas: mandate RTAS syscall filtering Nathan Lynch
2022-11-22  4:20   ` Andrew Donnellan
2022-11-18 15:07 ` [PATCH 10/13] powerpc/rtas: improve function information lookups Nathan Lynch
2022-11-23  2:51   ` Andrew Donnellan
2022-11-23 19:32     ` Nick Child
2022-11-24  3:28       ` Andrew Donnellan
2022-11-28 21:19         ` Nathan Lynch
2022-11-29  0:08     ` Nathan Lynch
2022-11-29  7:23       ` Andrew Donnellan
2022-11-29 15:33         ` Nathan Lynch
2022-11-23 20:06   ` Nick Child
2022-11-28 21:57     ` Nathan Lynch
2022-11-18 15:07 ` [PATCH 11/13] powerpc/rtas: strengthen do_enter_rtas() type safety, drop inline Nathan Lynch
2022-11-23  3:23   ` Andrew Donnellan
2022-11-28  2:37   ` Nicholas Piggin
2022-11-18 15:07 ` [PATCH 12/13] powerpc/tracing: tracepoints for RTAS entry and exit Nathan Lynch
2022-11-28  2:54   ` Nicholas Piggin
2022-11-18 15:07 ` [PATCH 13/13] powerpc/rtas: place tracepoints in do_enter_rtas() Nathan Lynch
2022-11-28  3:07   ` Nicholas Piggin
2022-11-28 23:44     ` Nathan Lynch
2022-11-29  0:49       ` Michael Ellerman
2022-11-29 20:24         ` Nathan Lynch
2022-11-30  7:43           ` Michael Ellerman
2022-11-29  6:47       ` Nicholas Piggin
2022-12-08 12:40 ` [PATCH 00/13] RTAS maintenance Michael Ellerman

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=2bb6286d131fe34b4358a962f708ee0a9b85e166.camel@linux.ibm.com \
    --to=ajd@linux.ibm.com \
    --cc=ldufour@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nathanl@linux.ibm.com \
    --cc=nnac123@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=tyreld@linux.ibm.com \
    /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.