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: <20170324015936.GA366@jagdpanzerIV.localdomain>
Date:   Fri, 24 Mar 2017 10:59:36 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

On (03/23/17 09:51), Peter Zijlstra wrote:
[..]
> > > sysrq runs from interrupt context, right? Should be able to do wakeups.
> > 
> > what I though about was -
> > 	what if there are 'misbehaving' higher prio tasks all the time?
> > 	the existing sysrq would attempt to do printing from irq context
> > 	so it doesn't care about run queues.
> > 
> > does it make sense to you?
> 
> Ah, that's what you meant. Yeah, dunno, I'm still unconvinced about the
> whole printk thread thing.

I see your point.
but I can't think of alternatives that would fix all those lockups and
stalls and at the same time have better guarantees than printk_kthread.


> Also those function names are horrifically long.

right. not happy with the naming either.

so what I'm thinking about right now is:

we have that thing which we call "old printk" mode, which is not
really informative. and my proposal is rename "old" mode and use
"printk rescue" mode instead. because we switch to that mode when
we are trying to "rescue" kernel logs. so the API can be something
like
		printk_rescue_on()
		printk_rescue_off()

opinions?



--- random thoughts ---

another thing that bothers me a bit is that we need to place those
printk_rescue_on/printk_rescue_off switches all over the kernel.
sort of a root cause [in some of the cases] here is the fact that
we don't have any feedback from printk_kthread in vprintk_emit():
	does printk_kthread make any progress?
	do we flush messages to the serial console?
	etc.

and we've got everything we need to have such a feedback in
vprintk_emit():

	a) console is not suspended so console_unlock() can call console drivers
	b) printk_kthread != NULL
	c) we are not in enforced rescue/emergency mode
	d) `log_next_seq' moves forward (always `true', we are in vprintk_emit())
	e) `console_seq' stands still

so we can have an automatic rescue mode fallback in vprintk_emit().
if (a)-(e) are true then we give up on waking up printk_kthread,
switch to rescue mode and attempt to console_trylock() directly from
vprintk_emit(). the part that sucks here is that we need to give
printk_kthread some time to catch up. for instance, if (e) is true
for the past 50 invocations of vprintk_emit(), IOW:

	- we added 50 lines to printk
	- none have been printed on the serial console

then we
	- declare rescue
	- do console_trylock() instead of wake_up() //unless in deferred vprintk_emit()


50 is completely made up. can be 100, or 10, or anything else.


and we can jump between rescue-normal printk modes, so this should
also return back the throttling of tasks which printk() a lot (item
(2) in patch set cover letter) that we used to have.


thoughts?

	-ss