[PATCH] printk: defer_console_output: do not assume interrupts disabled

[PATCH] printk: defer_console_output: do not assume interrupts disabled

[John Ogness]

With commit 458df9fd4815 ("printk: remove separate printk_sched
buffers and use printk buf instead") defer_console_output() was
changed to no longer disable interrupts. However, it used the
function __this_cpu_or(), which assumes interrupts disabled. That
also should have been changed to this_cpu_or().

Although defer_console_output() is mostly used when interrupts are
disabled, this is not always the case. One example is
get_random_bytes(), which is often called with interrupts enabled.

  get_random_bytes()
    warn_unseeded_randomness()
      printk_deferred()

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 82abfaf3c2aa..164ccdb9423e 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3262,7 +3262,7 @@ void defer_console_output(void)
 		return;
 
 	preempt_disable();
-	__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
+	this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
 	irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
 	preempt_enable();
 }

base-commit: 88808fbbead481aedb46640a5ace69c58287f56a
-- 
2.30.2

Re: [PATCH] printk: defer_console_output: do not assume interrupts disabled

[Sebastian Andrzej Siewior]

On 2022-02-03 12:35:15 [+0106], John Ogness wrote:
> With commit 458df9fd4815 ("printk: remove separate printk_sched
> buffers and use printk buf instead") defer_console_output() was
> changed to no longer disable interrupts. However, it used the
> function __this_cpu_or(), which assumes interrupts disabled. That
> also should have been changed to this_cpu_or().
> 
> Although defer_console_output() is mostly used when interrupts are
> disabled, this is not always the case. One example is
> get_random_bytes(), which is often called with interrupts enabled.

It is okay for __this_cpu_or() to be invoked with disabled preemption if
that is true for all callers. Disabled interrupts or not is not
important as long as there are no callers in_irq(). I believe that there
are callers in_irq() and therefore this_cpu_or() is correct.

>   get_random_bytes()
>     warn_unseeded_randomness()
>       printk_deferred()
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

Sebastian

Re: [PATCH] printk: defer_console_output: do not assume interrupts disabled

[Sergey Senozhatsky]

On (22/02/03 12:35), John Ogness wrote:
> With commit 458df9fd4815 ("printk: remove separate printk_sched
> buffers and use printk buf instead") defer_console_output() was
> changed to no longer disable interrupts. However, it used the
> function __this_cpu_or(), which assumes interrupts disabled. That
> also should have been changed to this_cpu_or().
> 
> Although defer_console_output() is mostly used when interrupts are
> disabled, this is not always the case. One example is
> get_random_bytes(), which is often called with interrupts enabled.
> 
>   get_random_bytes()
>     warn_unseeded_randomness()
>       printk_deferred()
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>

[PATCH v2] printk: defer_console_output: use atomic update

[John Ogness]

The per-cpu @printk_pending variable can be updated from
sleepable contexts, such as:

  get_random_bytes()
    warn_unseeded_randomness()
      printk_deferred()
        defer_console_output()

and can be updated from interrupt contexts, such as:

  handle_irq_event_percpu()
    __irq_wake_thread()
      wake_up_process()
        try_to_wake_up()
          select_task_rq()
            select_fallback_rq()
              printk_deferred()
                defer_console_output()

and can be updated from NMI contexts, such as:

  vprintk()
    if (in_nmi()) defer_console_output()

Therefore this_cpu_or(), the atomic variant of __this_cpu_or(),
should be used to update the variable.

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 Change from v1:
 
 Sebastian comments made it clear that the v1 title and message were not
 correctly specifying the problem or the reason for the fix. I hope this
 text is clearer.

 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 82abfaf3c2aa..164ccdb9423e 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3262,7 +3262,7 @@ void defer_console_output(void)
 		return;
 
 	preempt_disable();
-	__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
+	this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
 	irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
 	preempt_enable();
 }

base-commit: dfd42facf1e4ada021b939b4e19c935dcdd55566
-- 
2.30.2

Re: [PATCH v2] printk: defer_console_output: use atomic update

[Petr Mladek]

On Mon 2022-02-07 10:52:20, John Ogness wrote:
> The per-cpu @printk_pending variable can be updated from
> sleepable contexts, such as:
> 
>   get_random_bytes()
>     warn_unseeded_randomness()
>       printk_deferred()
>         defer_console_output()
> 
> and can be updated from interrupt contexts, such as:
> 
>   handle_irq_event_percpu()
>     __irq_wake_thread()
>       wake_up_process()
>         try_to_wake_up()
>           select_task_rq()
>             select_fallback_rq()
>               printk_deferred()
>                 defer_console_output()
> 
> and can be updated from NMI contexts, such as:
> 
>   vprintk()
>     if (in_nmi()) defer_console_output()
> 
> Therefore this_cpu_or(), the atomic variant of __this_cpu_or(),
> should be used to update the variable.
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

Makes sense.

The patch has been committed into printk/linux.git, branch for-5.18.

Best Regards,
Petr

Re: [PATCH v2] printk: defer_console_output: use atomic update

[John Ogness]

Hi Petr,

On 2022-02-10, Petr Mladek <pmladek@suse.com> wrote:
> The patch has been committed into printk/linux.git, branch for-5.18.

Sebastian also pointed out that the use of __this_cpu_xchg() is the same
problem with the same variable for the same reason. We should fold that
change into the patch as well. The patch will followup this message.

@Sergey: I dropped your Reviewed-by since the code changed.

John

[PATCH v3] printk: use atomic updates for klogd work

[John Ogness]

The per-cpu @printk_pending variable can be updated from
sleepable contexts, such as:

  get_random_bytes()
    warn_unseeded_randomness()
      printk_deferred()
        defer_console_output()

and can be updated from interrupt contexts, such as:

  handle_irq_event_percpu()
    __irq_wake_thread()
      wake_up_process()
        try_to_wake_up()
          select_task_rq()
            select_fallback_rq()
              printk_deferred()
                defer_console_output()

and can be updated from NMI contexts, such as:

  vprintk()
    if (in_nmi()) defer_console_output()

Therefore the atomic variant of the updating functions must be used.

Replace __this_cpu_xchg() with this_cpu_xchg().
Replace __this_cpu_or() with this_cpu_or().

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 Changes:

 v3: also fix __this_cpu_xchg() usage

 v2: fix commit message

 kernel/printk/printk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 82abfaf3c2aa..c7280b40de6c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3228,7 +3228,7 @@ static DEFINE_PER_CPU(int, printk_pending);
 
 static void wake_up_klogd_work_func(struct irq_work *irq_work)
 {
-	int pending = __this_cpu_xchg(printk_pending, 0);
+	int pending = this_cpu_xchg(printk_pending, 0);
 
 	if (pending & PRINTK_PENDING_OUTPUT) {
 		/* If trylock fails, someone else is doing the printing */
@@ -3262,7 +3262,7 @@ void defer_console_output(void)
 		return;
 
 	preempt_disable();
-	__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
+	this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
 	irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
 	preempt_enable();
 }
-- 
2.30.2

Re: [PATCH v3] printk: use atomic updates for klogd work

[Sergey Senozhatsky]

On (22/02/11 12:29), John Ogness wrote:
> The per-cpu @printk_pending variable can be updated from
> sleepable contexts, such as:
> 
>   get_random_bytes()
>     warn_unseeded_randomness()
>       printk_deferred()
>         defer_console_output()
> 
> and can be updated from interrupt contexts, such as:
> 
>   handle_irq_event_percpu()
>     __irq_wake_thread()
>       wake_up_process()
>         try_to_wake_up()
>           select_task_rq()
>             select_fallback_rq()
>               printk_deferred()
>                 defer_console_output()
> 
> and can be updated from NMI contexts, such as:
> 
>   vprintk()
>     if (in_nmi()) defer_console_output()
> 
> Therefore the atomic variant of the updating functions must be used.
> 
> Replace __this_cpu_xchg() with this_cpu_xchg().
> Replace __this_cpu_or() with this_cpu_or().
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

FWIW
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>

Re: [PATCH v3] printk: use atomic updates for klogd work

[Petr Mladek]

On Fri 2022-02-11 12:29:37, John Ogness wrote:
> The per-cpu @printk_pending variable can be updated from
> sleepable contexts, such as:
> 
>   get_random_bytes()
>     warn_unseeded_randomness()
>       printk_deferred()
>         defer_console_output()
> 
> and can be updated from interrupt contexts, such as:
> 
>   handle_irq_event_percpu()
>     __irq_wake_thread()
>       wake_up_process()
>         try_to_wake_up()
>           select_task_rq()
>             select_fallback_rq()
>               printk_deferred()
>                 defer_console_output()
> 
> and can be updated from NMI contexts, such as:
> 
>   vprintk()
>     if (in_nmi()) defer_console_output()
> 
> Therefore the atomic variant of the updating functions must be used.
> 
> Replace __this_cpu_xchg() with this_cpu_xchg().
> Replace __this_cpu_or() with this_cpu_or().
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

The v3 patch is comitted in printk/linux.git, branch for.5.18.

I have replaced v2 version with it.

Best Regards,
Petr

Re: [PATCH v2] printk: defer_console_output: use atomic update

[Sergey Senozhatsky]

On (22/02/11 12:28), John Ogness wrote:
> Hi Petr,
> 
> On 2022-02-10, Petr Mladek <pmladek@suse.com> wrote:
> > The patch has been committed into printk/linux.git, branch for-5.18.
> 
> Sebastian also pointed out that the use of __this_cpu_xchg() is the same
> problem with the same variable for the same reason. We should fold that
> change into the patch as well. The patch will followup this message.

But that __this_cpu_xchg() (that this lol) can only be performed form the
IRQ context. Can you please elaborate what is the problem with it?

Re: [PATCH v2] printk: defer_console_output: use atomic update

[Sergey Senozhatsky]

On (22/02/14 14:32), Sergey Senozhatsky wrote:
> On (22/02/11 12:28), John Ogness wrote:
> > Hi Petr,
> > 
> > On 2022-02-10, Petr Mladek <pmladek@suse.com> wrote:
> > > The patch has been committed into printk/linux.git, branch for-5.18.
> > 
> > Sebastian also pointed out that the use of __this_cpu_xchg() is the same
> > problem with the same variable for the same reason. We should fold that
> > change into the patch as well. The patch will followup this message.
> 
> But that __this_cpu_xchg() (that this lol) can only be performed form the
> IRQ context. Can you please elaborate what is the problem with it?

Oh, it can race with NMI, yeah.