linux-kernel - Re: [PATCH] printk: stop spining waiter when console resume to flush prb

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: <72443c6d-b70b-0e36-bab0-87705a1d8019@huawei.com>
Date:   Fri, 7 May 2021 15:33:26 +0800
From:   luojiaxing <luojiaxing@...wei.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Petr Mladek <pmladek@...e.com>
CC:     <sergey.senozhatsky@...il.com>, <rostedt@...dmis.org>,
        <john.ogness@...utronix.de>, <linux-kernel@...r.kernel.org>,
        <linuxarm@...wei.com>, <bobo.shaobowang@...wei.com>
Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush
 prb


On 2021/5/6 22:12, Sergey Senozhatsky wrote:
> On (21/05/06 23:07), Sergey Senozhatsky wrote:
>> Can we count the number of lines that we print from the `current` context
>> in console_unlock() and if after N messages there is no console_lock waiter
>> waiting for the `current` to handover console lock ownership, then create
>> one: schedule IRQ work that will become a console lock owner, spin on
>> console lock and call console_unlock() once it acquired the ownership.
>> That 'artificial' console lock owner will do the same - print N
>> messages, if nothing wants to become a console lock owner then it'll
>> queue another IRQ work.
> Or even simpler
>
> console_unlock()
> {
> 	...
>
> 	if (printed_messages > limit && !console_lock_spinning_disable_and_check()) {
> 		printk_safe_exit_irqrestore(flags);
>
> 		console_locked = 0;
> 		up_console_sem();
>
> 		defer_console_output();
> 		return;
> 	}


Hi,  Sergey, I test this,  it works.


But, I have a doubt. If the log buffer exceeds limit, we can schedule 
IRQ work to become the console lock owner and let current context return.

So why not just let the IRQ work process the console output without 
limit? To be clear, driver call printk() only care about the correct 
sequence of timestamps

and does not care when the print is output. Actually, I wonder if the 
driver can only cache the print and queue the output tasks to a 
workqueue to return, and then return directly?


I don't know if this is a stupid idea, because I'm not familiar with printk.


Thanks

Jiaxing


> 	...
> }
>
> .
>