linux-kernel - Re: [PATCH RT] printk: console must not schedule for drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Apr 2020 18:34:16 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: [PATCH RT] printk: console must not schedule for drivers

On 2020-04-06 23:22:17 [+0200], John Ogness wrote:
> Even though the printk kthread is always preemptible, it is still not
> allowed to call cond_resched() from within console drivers. The
> task may become non-preemptible in the console driver call chain. For
> example, vt_console_print() takes a spinlock and then can call into
> fbcon_redraw(), which can conditionally invoke cond_resched():
> 
> BUG: sleeping function called from invalid context at kernel/printk/printk.c:2322
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 177, name: printk
> CPU: 0 PID: 177 Comm: printk Not tainted 5.6.2-00011-ga536059557f1d9 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
> Call Trace:
>  dump_stack+0x66/0x8b
>  ___might_sleep+0x102/0x120
>  console_conditional_schedule+0x24/0x30
>  fbcon_redraw+0x96/0x1c0
>  ? fbcon_cursor+0x100/0x190
>  fbcon_scroll+0x556/0xd70
>  con_scroll+0x147/0x1e0
>  lf+0x9e/0xb0
>  vt_console_print+0x253/0x3d0
>  printk_kthread_func+0x1d5/0x3b0
> 
> Disable cond_resched() for the call into the console drivers.

Interesting. So you get a report and I don't?

I have also patch related questions :)
- So before the re-rewrite, console_unlock() set this 0 before invoking
  the console drivers so it was always 0. I assume it was called with
  disabled interrupts.

- Is there a scenario in fbcon where this function is invoked and
  console_may_schedule is not 0?

Sebastian