linux-kernel - Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

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]

Message-ID: <20170403115311.GC7867@jagdpanzerIV.localdomain>
Date:   Mon, 3 Apr 2017 20:53:11 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

On (03/06/17 21:45), Sergey Senozhatsky wrote:
[..]
>  printk kthread changes the behavior of printk in one _corner case_.
>  The corner case is quite interesting and actually consists of two corner
>  cases. Suppose on SMP system there is only one CPU that printk()-s a lot,
>  the rest of CPUs don't lock console_sem and don't printk(). Previously
>  that printing CPU had been throttling itself (*) because of console drivers
>  call for every printk():
> 
>           CPU0
> 
>        printk("a")
>         console_unlock()
>          call_console_drivers("a")
> 
>          ...
> 
>        printk("z")
>         console_unlock()
>          call_console_drivers("z")
> 
>  * Given that no other CPU locks the console_sem.
> 
>  With printk kthread the case turns into this one:
> 
>           CPU0                               CPU1
> 
>        printk("a")
>        wake_up printk_kthread
>        ...                               printk_kthread
>        printk("k")                        console_unlock()
>        ...                                 call_console_drivers("a")
>        printk("z")                         call_console_drivers("b")
>                                            call_console_drivers("c")
>                                            ...
> 
> 
>  The second 'corner case' part here is that CPU0 may be much faster
>  than printing CPU, which may result in dropped printk messages.
> 
>  This all is absolutely possible even with out the printk-kthread.
>  A single console_lock() call from CPUx will result in exactly the
>  same condition. So it's not necessarily a regression. But there may
>  be some scenarios in the kernel that may suffer from this change.
>  From the top of my head -- sysrq backtrace dump, and, probably, OOM
>  print out and backtrace dump.

there is another possibility here.

being always reschedulable potentially can put us at risk of having
unpleasant situations when printk_kthread is getting preempted too
often (well, who knows what can happen on the system), which can slow
down logbuf emit process (printk_kthread) up to the point when printk()
CPUs will force log_store() to begin dropping the messages. this can
happen.

	-ss