linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Lynch via B4 Relay <devnull+nathanl.linux.ibm.com@kernel.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	 "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
	 Brian King <brking@linux.ibm.com>,
	 Christophe Leroy <christophe.leroy@csgroup.eu>,
	 John Ogness <john.ogness@linutronix.de>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	 Petr Mladek <pmladek@suse.com>,
	 Sergey Senozhatsky <senozhatsky@chromium.org>,
	 Steven Rostedt <rostedt@goodmis.org>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: [PATCH RFC 2/5] dump_stack: Allow update of arch description string at runtime
Date: Thu, 18 Jan 2024 09:25:13 -0600	[thread overview]
Message-ID: <20240118-update-dump-stack-arch-str-v1-2-5c0f98d017b5@linux.ibm.com> (raw)
In-Reply-To: <20240118-update-dump-stack-arch-str-v1-0-5c0f98d017b5@linux.ibm.com>

From: Nathan Lynch <nathanl@linux.ibm.com>

The IBM PowerVM platform (targeted by powerpc/pseries) exposes the
physical machine model and firmware version to partitions (guests),
and this information is used to populate the arch description string,
e.g.

  IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 \
    of:IBM,FW860.50 (SV860_146) hv:phyp pSeries

The platform supports live migration of partitions between different
machine models and firmware versions, so the arch description string
set at boot can become inaccurate, potentially misleading anyone who's
analyzing stack traces produced after a migration.

Introduce a RCU-guarded pointer to the current arch description
string, initializing it to the static buffer populated at boot. Add to
dump_stack_print_info() a RCU read-side critical section that accesses
the buffer through this pointer. The majority of architectures which
don't need to update the string after boot incur only an additional
indirection.

As for platforms which do need that ability, they can use
dump_stack_update_arch_desc(), which allocates and formats a new
buffer, updates the pointer, and if appropriate frees the previous
buffer.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
 include/linux/printk.h |  5 +++++
 lib/dump_stack.c       | 54 ++++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 8ef499ab3c1e..6138ae019d2a 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -187,6 +187,7 @@ u32 log_buf_len_get(void);
 void log_buf_vmcoreinfo_setup(void);
 void __init setup_log_buf(int early);
 __printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...);
+__printf(1, 2) void dump_stack_update_arch_desc(const char *fmt, ...);
 void dump_stack_print_info(const char *log_lvl);
 void show_regs_print_info(const char *log_lvl);
 extern asmlinkage void dump_stack_lvl(const char *log_lvl) __cold;
@@ -253,6 +254,10 @@ static inline __printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...)
 {
 }
 
+static inline __printf(1, 2) void dump_stack_update_arch_desc(const char *fmt, ...)
+{
+}
+
 static inline void dump_stack_print_info(const char *log_lvl)
 {
 }
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 1057f102f6f2..bd497e7797ee 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -8,15 +8,18 @@
 #include <linux/buildid.h>
 #include <linux/cache.h>
 #include <linux/export.h>
+#include <linux/rcupdate.h>
 #include <linux/sched.h>
 #include <linux/sched/debug.h>
 #include <linux/smp.h>
+#include <linux/spinlock.h>
 #include <linux/atomic.h>
 #include <linux/kexec.h>
 #include <linux/utsname.h>
 #include <linux/stop_machine.h>
 
 static char dump_stack_arch_desc_str[128] __ro_after_init;
+static const char *dump_stack_arch_desc_ptr = dump_stack_arch_desc_str;
 
 /**
  * dump_stack_set_arch_desc - set arch-specific str to show with task dumps
@@ -28,7 +31,7 @@ static char dump_stack_arch_desc_str[128] __ro_after_init;
  * arch wants to make use of such an ID string, it should initialize this
  * as soon as possible during boot.
  */
-void __init dump_stack_set_arch_desc(const char *fmt, ...)
+void dump_stack_set_arch_desc(const char *fmt, ...)
 {
 	va_list args;
 
@@ -38,6 +41,45 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
 	va_end(args);
 }
 
+/**
+ * dump_stack_update_arch_desc() - Update the arch description string at runtime.
+ * @fmt: printf-style format string
+ * @...: arguments for the format string
+ *
+ * A runtime counterpart of dump_stack_set_arch_desc(). Arch code
+ * should use this when the arch description set at boot potentially
+ * has become inaccurate, such as after a guest migration.
+ *
+ * Context: May sleep.
+ */
+void dump_stack_update_arch_desc(const char *fmt, ...)
+{
+	static DEFINE_SPINLOCK(arch_desc_update_lock);
+	const char *old;
+	const char *new;
+	va_list args;
+
+	va_start(args, fmt);
+	new = kvasprintf(GFP_KERNEL, fmt, args);
+	va_end(args);
+
+	if (!new)
+		return;
+
+	spin_lock(&arch_desc_update_lock);
+	old = rcu_replace_pointer(dump_stack_arch_desc_ptr, new,
+				  lockdep_is_held(&arch_desc_update_lock));
+	spin_unlock(&arch_desc_update_lock);
+
+	/*
+	 * Avoid freeing the static buffer initialized during boot.
+	 */
+	if (old == dump_stack_arch_desc_str)
+		return;
+
+	kfree_rcu_mightsleep(old);
+}
+
 #if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID)
 #define BUILD_ID_FMT " %20phN"
 #define BUILD_ID_VAL vmlinux_build_id
@@ -55,6 +97,8 @@ void __init dump_stack_set_arch_desc(const char *fmt, ...)
  */
 void dump_stack_print_info(const char *log_lvl)
 {
+	const char *arch_str;
+
 	printk("%sCPU: %d PID: %d Comm: %.20s %s%s %s %.*s" BUILD_ID_FMT "\n",
 	       log_lvl, raw_smp_processor_id(), current->pid, current->comm,
 	       kexec_crash_loaded() ? "Kdump: loaded " : "",
@@ -63,9 +107,11 @@ void dump_stack_print_info(const char *log_lvl)
 	       (int)strcspn(init_utsname()->version, " "),
 	       init_utsname()->version, BUILD_ID_VAL);
 
-	if (dump_stack_arch_desc_str[0] != '\0')
-		printk("%sHardware name: %s\n",
-		       log_lvl, dump_stack_arch_desc_str);
+	rcu_read_lock();
+	arch_str = rcu_dereference(dump_stack_arch_desc_ptr);
+	if (arch_str[0] != '\0')
+		printk("%sHardware name: %s\n", log_lvl, arch_str);
+	rcu_read_unlock();
 
 	print_worker_info(log_lvl, current);
 	print_stop_info(log_lvl, current);

-- 
2.43.0


  parent reply	other threads:[~2024-01-18 15:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 15:25 [PATCH RFC 0/5] dump_stack: Allow runtime updates of the hardware description Nathan Lynch via B4 Relay
2024-01-18 15:25 ` [PATCH RFC 1/5] dump_stack: Make arch description buffer __ro_after_init Nathan Lynch via B4 Relay
2024-01-18 15:25 ` Nathan Lynch via B4 Relay [this message]
2024-01-18 15:25 ` [PATCH RFC 3/5] powerpc/prom: Add CPU info to hardware description string later Nathan Lynch via B4 Relay
2024-01-18 15:25 ` [PATCH RFC 4/5] powerpc/pseries: Prepare pseries_add_hw_description() for runtime use Nathan Lynch via B4 Relay
2024-01-18 15:25 ` [PATCH RFC 5/5] powerpc/pseries: Update hardware description string after migration Nathan Lynch via B4 Relay

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=20240118-update-dump-stack-arch-str-v1-2-5c0f98d017b5@linux.ibm.com \
    --to=devnull+nathanl.linux.ibm.com@kernel.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=brking@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathanl@linux.ibm.com \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).