linux-kernel - Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

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:   Mon, 15 Jan 2018 12:50:13 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Tejun Heo <tj@...nel.org>, akpm@...ux-foundation.org,
        linux-mm@...ck.org, Cong Wang <xiyou.wangcong@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        rostedt@...e.goodmis.org, Byungchul Park <byungchul.park@....com>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Mon 2018-01-15 11:17:43, Petr Mladek wrote:
> PS: Sergey, you have many good points. The printk-stuff is very
> complex and we could spend years discussing the perfect solution.

BTW: One solution that comes to my mind is based on ideas
already mentioned in this thread:

void console_unlock(void)
{
	disable_preemtion();

	while(pending_message) {

	    call_console_drivers();

	    if (too_long_here() && current != printk_kthread) {
	       wake_up_process(printk_kthread())

	}

	enable_preemtion();
}

bool too_long_here(void)
{
	return should_resched();
or
	return spent_here() > 1 / HZ / 2;
or
	what ever we agree on
}

int printk_kthread_func(void *data)
{
	while(1) {
		 if (!pending_messaged)
			schedule();

		if (console_trylock_spinning())
			console_unlock();

		cond_resched();
	}
}

It means that console_unlock() will aggressively push messages
with disabled preemption. It will wake up printk_kthread when
it is pushing too long. The printk_kthread would try
to steal the lock and take over the job.

If the system is in reasonable state, printk_kthread should
succeed and avoid softlockup. The offload should be more safe
than a pure wake_up_process().

If printk_kthread is not able to take over the job, it
might suggest that the offload is not safe and the softlockup
is inevitable.

One question is how to avoid softlockup when console_unlock()
is called from printk_kthread. I think that printk_kthread
should release console_lock and call cond_resched from
time to time. It means that the printing will be less
aggressive but anyone could continue flushing the console.
If there are no new messages, it is probably acceptable
to be less aggressive with flushing the messages.

Anyway, this should be more safe than a direct offload
if we agree that getting the messages out is more
important than a possible softlockup.

If this is not enough, I would start thinking about
throttling writers.

Finally, this is all a future work that can be done
and discussed later.

Best Regards,
Petr