Re: [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Using guard(preempt) instead of guard(preempt_notrace) risks infinite tracing recursion.
- [Low] Missing semicolons after function/macro calls in the fallback implementation of WARN_ON_DEFERRED.
- [Low] Undeclared dependency on <linux/cleanup.h> and <linux/preempt.h> for guard(preempt).
--

commit 2038be49d63c72765117592b09ef0f46f0eef9d8
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

bug: Provide WARN_ON.*DEFERRED() macros for console deferred output

This commit introduces a deferred version of the WARN_ON() macro to delay
flushing the console until a later context. It implements WARN_ON_DEFERRED
and WARN_ON_ONCE_DEFERRED using printk_deferred_enter/exit() and extends
__report_bug() to handle the deferred case.

> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 09e8eccee8ed9..1e3ff00f709b8 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h

[ ... ]

> @@ -159,6 +180,19 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
>  })
>  #endif
>  
> +#ifndef WARN_ON_DEFERRED
> +#define WARN_ON_DEFERRED(condition) ({					\
> +	int __ret_warn_on = !!(condition);				\
> +	if (unlikely(__ret_warn_on)) {					\
> +		guard(preempt)();					\

[Severity: High]
Does this risk infinite recursion if WARN_ON_DEFERRED() is called from a
tracing context?

guard(preempt) expands to preempt_disable(), which is a traceable function. If
a deferred warning occurs in traced code, disabling preemption will re-trigger
the tracer, which may again trigger the warning.

Should this use guard(preempt_notrace)() to match the preempt_disable_notrace()
used in __report_bug()?

[Severity: Low]
Does this introduce an undeclared dependency on <linux/cleanup.h> and
<linux/preempt.h> for guard()?

Using WARN_ON_DEFERRED() in a file that does not indirectly include these
headers might lead to build failures on architectures using this fallback macro.

> +		printk_deferred_enter()					\
> +		__WARN();						\
> +		printk_deferred_exit()					\

[Severity: Low]
Are there missing semicolons after the printk_deferred_enter() and
printk_deferred_exit() calls?

This looks like it will cause a syntax error on architectures that do not
define __WARN_FLAGS and rely on this fallback macro.

> +	}								\
> +	unlikely(__ret_warn_on);					\
> +})
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623142650.265721-1-bigeasy@linutronix.de?part=1