linux-kernel - Re: [RFC][PATCHv6 00/12] 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: <20171221065232.GB385@jagdpanzerIV>
Date:   Thu, 21 Dec 2017 15:52:32 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     sergey.senozhatsky.work@...il.com, mhocko@...nel.org,
        rostedt@...dmis.org, pmladek@...e.com, tj@...nel.org,
        sergey.senozhatsky@...il.com, jack@...e.cz,
        akpm@...ux-foundation.org, peterz@...radead.org, rjw@...ysocki.net,
        pavel@....cz, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hi Tetsuo,

On (12/20/17 21:06), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
>
[..]
>
> Anyway, the rule that "do not try to printk() faster than the kernel can
> write to consoles" will remain no matter how printk() changes.

and the "faster than the kernel can write to consoles" is tricky.
it does not depend ONLY on the performance of underlying console
devices. but also on the scheduler and IRQs. simply because of the
way we print:

void console_unlock(void)
{
	for (;;) {
		local_irq_save();

		text = pick_the_next_pending_logbuf_message();

		call_console_drivers(text);
		local_irq_enable();
				^^^^ preemption + irqs
	}
}

on my board call_console_drivers() can spend up to 0.01 of a second
printing a _single_ message. which basically means that I'm guaranteed
to have preemption in console_unlock() under console_sem after every
line it prints [if console_unlock() is invoked from preemptible context].
this, surely, has huge impact on "do not try to printk() faster than
this".

but there are more points in my "why the patch doesn't work for me"
email than just "preemption in console_unlock()".

	-ss