vprintk_deferred() is useful for implementing runtime verification
reactors. Make it public.

Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
---
v12:
  Add "static inline" to fix build issue when CONFIG_PRINTK=n
---
 include/linux/printk.h   | 5 +++++
 kernel/printk/internal.h | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 5b462029d03c..d886ec98fbbd 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -154,6 +154,7 @@ int vprintk_emit(int facility, int level,
 
 asmlinkage __printf(1, 0)
 int vprintk(const char *fmt, va_list args);
+__printf(1, 0) int vprintk_deferred(const char *fmt, va_list args);
 
 asmlinkage __printf(1, 2) __cold
 int _printk(const char *fmt, ...);
@@ -214,6 +215,10 @@ int vprintk(const char *s, va_list args)
 {
 	return 0;
 }
+static inline __printf(1, 0) int vprintk_deferred(const char *fmt, va_list args)
+{
+	return 0;
+}
 static inline __printf(1, 2) __cold
 int _printk(const char *s, ...)
 {
diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h
index 48a24e7b309d..bbed41ad29cf 100644
--- a/kernel/printk/internal.h
+++ b/kernel/printk/internal.h
@@ -72,7 +72,6 @@ int vprintk_store(int facility, int level,
 		  const char *fmt, va_list args);
 
 __printf(1, 0) int vprintk_default(const char *fmt, va_list args);
-__printf(1, 0) int vprintk_deferred(const char *fmt, va_list args);
 
 void __printk_safe_enter(void);
 void __printk_safe_exit(void);
-- 
2.39.5

On Wed,  9 Jul 2025 19:56:19 +0200
Nam Cao <namcao@linutronix.de> wrote:

> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index 5b462029d03c..d886ec98fbbd 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -154,6 +154,7 @@ int vprintk_emit(int facility, int level,
>  
>  asmlinkage __printf(1, 0)
>  int vprintk(const char *fmt, va_list args);
> +__printf(1, 0) int vprintk_deferred(const char *fmt, va_list args);
>  
>  asmlinkage __printf(1, 2) __cold
>  int _printk(const char *fmt, ...);
> @@ -214,6 +215,10 @@ int vprintk(const char *s, va_list args)
>  {
>  	return 0;
>  }
> +static inline __printf(1, 0) int vprintk_deferred(const char *fmt, va_list args)
> +{
> +	return 0;
> +}
>  static inline __printf(1, 2) __cold
>  int _printk(const char *s, ...)
>  {

All use cases I've seen throughout the kernel has the __printf() macro
on the line before the function. You're introducing a new formatting.
I'm thinking we should stay consistent:

__printf(1, 0)
int vprintk_deferred(const char *fmt, va_list args);

static inline __printf(1, 0)
int vprintk_deferred(const char *fmt, va_list args)
{
	return 0;
}


-- Steve

On Wed, Jul 09, 2025 at 02:49:14PM -0400, Steven Rostedt wrote:
> On Wed,  9 Jul 2025 19:56:19 +0200
> Nam Cao <namcao@linutronix.de> wrote:
> 
> > diff --git a/include/linux/printk.h b/include/linux/printk.h
> > index 5b462029d03c..d886ec98fbbd 100644
> > --- a/include/linux/printk.h
> > +++ b/include/linux/printk.h
> > @@ -154,6 +154,7 @@ int vprintk_emit(int facility, int level,
> >  
> >  asmlinkage __printf(1, 0)
> >  int vprintk(const char *fmt, va_list args);
> > +__printf(1, 0) int vprintk_deferred(const char *fmt, va_list args);
> >  
> >  asmlinkage __printf(1, 2) __cold
> >  int _printk(const char *fmt, ...);
> > @@ -214,6 +215,10 @@ int vprintk(const char *s, va_list args)
> >  {
> >  	return 0;
> >  }
> > +static inline __printf(1, 0) int vprintk_deferred(const char *fmt, va_list args)
> > +{
> > +	return 0;
> > +}
> >  static inline __printf(1, 2) __cold
> >  int _printk(const char *s, ...)
> >  {
> 
> All use cases I've seen throughout the kernel has the __printf() macro
> on the line before the function. You're introducing a new formatting.
> I'm thinking we should stay consistent:
> 
> __printf(1, 0)
> int vprintk_deferred(const char *fmt, va_list args);
> 
> static inline __printf(1, 0)
> int vprintk_deferred(const char *fmt, va_list args)
> {
> 	return 0;
> }

Yes we should.

It is possible that you make this amendment when/if you apply the patch, or
do you prefer me sending a new version?

Nam

On Wed, 9 Jul 2025 20:53:34 +0200
Nam Cao <namcao@linutronix.de> wrote:

> It is possible that you make this amendment when/if you apply the patch, or
> do you prefer me sending a new version?

I could do it, but if you send a new version, it will keep patchwork
automated. When I edit a patch, the status doesn't automatically get
updated due to the change.

I know it's minor, but could you send a v13? Then when the patch gets
accepted in mainline, it should automatically turn to Accept in
patchwork.

Thanks,

-- Steve

On Wed, Jul 09, 2025 at 03:04:52PM -0400, Steven Rostedt wrote:
> I could do it, but if you send a new version, it will keep patchwork
> automated. When I edit a patch, the status doesn't automatically get
> updated due to the change.
> 
> I know it's minor, but could you send a v13? Then when the patch gets
> accepted in mainline, it should automatically turn to Accept in
> patchwork.

Fine for me either way. I worked with other maintainers who prefer the
other way, so I had to ask.

Nam

On Wed, 9 Jul 2025 21:09:38 +0200
Nam Cao <namcao@linutronix.de> wrote:

> Fine for me either way. I worked with other maintainers who prefer the
> other way, so I had to ask.

I used to be one of those maintainers, but now that I'm relying on
patchwork so much, I found that full series does make the workflow
easier.

BTW, I also pull the series directly from patchwork, not the mailing
list or email.

-- Steve