KDB can interrupt any console to execute the "mirrored printing" at any
time, so add an exception to nbcon_context_try_acquire_direct to allow
to get the context if the current CPU is the same as kdb_printf_cpu.
This change will be necessary for the next patch, which fixes
kdb_msg_write to work with NBCON consoles by calling ->write_atomic on
such consoles. But to print it first needs to acquire the ownership of
the console, so nbcon_context_try_acquire_direct is fixed here.
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
---
include/linux/kdb.h | 16 ++++++++++++++++
kernel/printk/nbcon.c | 6 +++++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/linux/kdb.h b/include/linux/kdb.h
index ecbf819deeca..db9d73b12a1a 100644
--- a/include/linux/kdb.h
+++ b/include/linux/kdb.h
@@ -14,6 +14,7 @@
*/
#include <linux/list.h>
+#include <linux/smp.h>
/* Shifted versions of the command enable bits are be used if the command
* has no arguments (see kdb_check_flags). This allows commands, such as
@@ -207,11 +208,26 @@ static inline const char *kdb_walk_kallsyms(loff_t *pos)
/* Dynamic kdb shell command registration */
extern int kdb_register(kdbtab_t *cmd);
extern void kdb_unregister(kdbtab_t *cmd);
+
+/* Return true when KDB as locked for printing a message on this CPU. */
+static inline
+bool kdb_printf_on_this_cpu(void)
+{
+ /*
+ * We can use raw_smp_processor_id() here because the task could
+ * not get migrated when KDB has locked for printing on this CPU.
+ */
+ return unlikely(READ_ONCE(kdb_printf_cpu) == raw_smp_processor_id());
+}
+
#else /* ! CONFIG_KGDB_KDB */
static inline __printf(1, 2) int kdb_printf(const char *fmt, ...) { return 0; }
static inline void kdb_init(int level) {}
static inline int kdb_register(kdbtab_t *cmd) { return 0; }
static inline void kdb_unregister(kdbtab_t *cmd) {}
+
+static inline bool kdb_printf_on_this_cpu(void) { return false };
+
#endif /* CONFIG_KGDB_KDB */
enum {
KDB_NOT_INITIALIZED,
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index e1bf5409cb6b..5be018493909 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -10,6 +10,7 @@
#include <linux/export.h>
#include <linux/init.h>
#include <linux/irqflags.h>
+#include <linux/kdb.h>
#include <linux/kthread.h>
#include <linux/minmax.h>
#include <linux/panic.h>
@@ -249,13 +250,16 @@ static int nbcon_context_try_acquire_direct(struct nbcon_context *ctxt,
* since all non-panic CPUs are stopped during panic(), it
* is safer to have them avoid gaining console ownership.
*
- * If this acquire is a reacquire (and an unsafe takeover
+ * One exception is when kdb has locked for printing on this CPU.
+ *
+ * Second exception is a reacquire (and an unsafe takeover
* has not previously occurred) then it is allowed to attempt
* a direct acquire in panic. This gives console drivers an
* opportunity to perform any necessary cleanup if they were
* interrupted by the panic CPU while printing.
*/
if (panic_on_other_cpu() &&
+ !kdb_printf_on_this_cpu() &&
(!is_reacquire || cur->unsafe_takeover)) {
return -EPERM;
}
--
2.51.0On Thu 2025-10-16 11:47:56, Marcos Paulo de Souza wrote:
> KDB can interrupt any console to execute the "mirrored printing" at any
> time, so add an exception to nbcon_context_try_acquire_direct to allow
> to get the context if the current CPU is the same as kdb_printf_cpu.
>
> This change will be necessary for the next patch, which fixes
> kdb_msg_write to work with NBCON consoles by calling ->write_atomic on
> such consoles. But to print it first needs to acquire the ownership of
> the console, so nbcon_context_try_acquire_direct is fixed here.
>
> @@ -207,11 +208,26 @@ static inline const char *kdb_walk_kallsyms(loff_t *pos)
> /* Dynamic kdb shell command registration */
> extern int kdb_register(kdbtab_t *cmd);
> extern void kdb_unregister(kdbtab_t *cmd);
> +
> +/* Return true when KDB as locked for printing a message on this CPU. */
> +static inline
> +bool kdb_printf_on_this_cpu(void)
> +{
> + /*
> + * We can use raw_smp_processor_id() here because the task could
> + * not get migrated when KDB has locked for printing on this CPU.
> + */
> + return unlikely(READ_ONCE(kdb_printf_cpu) == raw_smp_processor_id());
> +}
> +
> #else /* ! CONFIG_KGDB_KDB */
> static inline __printf(1, 2) int kdb_printf(const char *fmt, ...) { return 0; }
> static inline void kdb_init(int level) {}
> static inline int kdb_register(kdbtab_t *cmd) { return 0; }
> static inline void kdb_unregister(kdbtab_t *cmd) {}
> +
> +static inline bool kdb_printf_on_this_cpu(void) { return false };
As the robot pointed out, this should be:
static inline bool kdb_printf_on_this_cpu(void) { return false; }
> +
> #endif /* CONFIG_KGDB_KDB */
> enum {
> KDB_NOT_INITIALIZED,
The rest looks good. With the above change:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
Hi Marcos,
kernel test robot noticed the following build errors:
[auto build test ERROR on 3a8660878839faadb4f1a6dd72c3179c1df56787]
url: https://github.com/intel-lab-lkp/linux/commits/Marcos-Paulo-de-Souza/printk-nbcon-Export-console_is_usable/20251016-225503
base: 3a8660878839faadb4f1a6dd72c3179c1df56787
patch link: https://lore.kernel.org/r/20251016-nbcon-kgdboc-v6-3-866aac60a80e%40suse.com
patch subject: [PATCH v6 3/5] printk: nbcon: Allow KDB to acquire the NBCON context
config: openrisc-allnoconfig (https://download.01.org/0day-ci/archive/20251017/202510170949.NTx9lt0p-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251017/202510170949.NTx9lt0p-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510170949.NTx9lt0p-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from kernel/kallsyms.c:19:
include/linux/kdb.h: In function 'kdb_printf_on_this_cpu':
>> include/linux/kdb.h:229:63: error: expected ';' before '}' token
229 | static inline bool kdb_printf_on_this_cpu(void) { return false };
| ^~
| ;
vim +229 include/linux/kdb.h
228
> 229 static inline bool kdb_printf_on_this_cpu(void) { return false };
230
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Fri 2025-10-17 09:25:53, kernel test robot wrote:
> Hi Marcos,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 3a8660878839faadb4f1a6dd72c3179c1df56787]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Marcos-Paulo-de-Souza/printk-nbcon-Export-console_is_usable/20251016-225503
> base: 3a8660878839faadb4f1a6dd72c3179c1df56787
> patch link: https://lore.kernel.org/r/20251016-nbcon-kgdboc-v6-3-866aac60a80e%40suse.com
> patch subject: [PATCH v6 3/5] printk: nbcon: Allow KDB to acquire the NBCON context
> config: openrisc-allnoconfig (https://download.01.org/0day-ci/archive/20251017/202510170949.NTx9lt0p-lkp@intel.com/config)
> compiler: or1k-linux-gcc (GCC) 15.1.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251017/202510170949.NTx9lt0p-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202510170949.NTx9lt0p-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> In file included from kernel/kallsyms.c:19:
> include/linux/kdb.h: In function 'kdb_printf_on_this_cpu':
> >> include/linux/kdb.h:229:63: error: expected ';' before '}' token
> 229 | static inline bool kdb_printf_on_this_cpu(void) { return false };
Great catch! This should be:
static inline bool kdb_printf_on_this_cpu(void) { return false; }
No need for v7. I could fix it when commtting the change.
BTW: It is interesting that the robot was so quick this time but
it did not catch it in the earlier versions of the patchset.
Maybe the robot had a summer vacation as well ;-)
I am just joking. I know that any resources are limited and
could not test everything. It is great to have the robot around.
Best Regards,
Petr
© 2016 - 2025 Red Hat, Inc.