linux-kernel - Re: [PATCH v10 1/2] printk: Make printk() completely async

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, 10 Aug 2016 14:17:55 -0700
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:	Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
	Tejun Heo <tj@...nel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Byungchul Park <byungchul.park@....com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	vlevenetz@...sol.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async

+Vladi/Greg,

On Wed, Apr 6, 2016 at 1:27 AM, Jan Kara <jack@...e.cz> wrote:
> On Mon 04-04-16 15:51:49, Andrew Morton wrote:

>> > +static int __init init_printk_kthread(void)
>> > +{
>> > +   struct task_struct *thread;
>> > +
>> > +   if (printk_sync)
>> > +           return 0;
>> > +
>> > +   thread = kthread_run(printk_kthread_func, NULL, "printk");
>>
>> This gets normal scheduling policy, so a spinning userspace SCHED_FIFO
>> task will block printk for ever.  This seems bad.
>
> I have to research this a bit but won't the SCHED_FIFO task that has
> potentially unbounded amount of work lockup the CPU even though it does
> occasional cond_resched()?

We are facing complete hogs because of the printk thread being a SCHED_FIFO
task and have this patch to fix it up for now.

Author: Vladislav Levenetz <vblagoev@...sol.com>
Date:   Wed Aug 10 13:58:00 2016 -0700

    SW-7786: printk: Lower the priority of printk thread

    Flooding the console (with a test module) in a tight loop indefinitely
    makes android user interface very sluggish. Opening YouTube app and the
    device hangs and becomes even more unresponsive to the point it
    completely hangs.

    The asynchronous printk thread is a SCHED FIFO thread with priority
    MAX_RT_PRIO - 1. If we create it as a simple thread (i.e. no SCHED FIFO)
    instead, we observe much better performance using the same printk flood
    test. We don't even notice any kind of sluggishness during device usage.
    We can play a YouTube clip smoothly and use the device normally in
    general.  The kernel log looks fine as well, as the flood of messages
    continue normally.

    Signed-off-by: Vladislav Levenetz <vblagoev@...sol.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 kernel/printk/printk.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c32872872cb6..ad5b30e5e6d9 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2856,9 +2856,6 @@ static int printk_kthread_func(void *data)
 static int __init_printk_kthread(void)
 {
        struct task_struct *thread;
-       struct sched_param param = {
-               .sched_priority = MAX_RT_PRIO - 1,
-       };

        if (!printk_kthread_can_run || printk_sync || printk_kthread)
                return 0;
@@ -2870,7 +2867,6 @@ static int __init_printk_kthread(void)
                return PTR_ERR(thread);
        }

-       sched_setscheduler(thread, SCHED_FIFO, &param);
        printk_kthread = thread;
        return 0;
 }