Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

From	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread
Date	2017-07-04 09:00 +0200
Message-ID	<tZpYt-4Iv-7@gated-at.bofh.it> (permalink)
References	(5 earlier) <tY404-5YH-51@gated-at.bofh.it> <tY4jn-64M-7@gated-at.bofh.it> <tZ7yy-BB-7@gated-at.bofh.it> <tZfmq-5Q9-35@gated-at.bofh.it> <tZozn-3Ky-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On (07/04/17 14:26), Sergey Senozhatsky wrote:
[..]
> not sure if we can properly throttle printk in all of the cases.
> we know that console_sem is locked, but we don't know what for.
> is CPU that owns the console_sem is now in console_unlock() or
> somewhere in fbcon, or anywhere else. we probably need not to
> throttle printk() if we know that console_sem is already locked
> by this_cpu and we simply call printk either from IRQ that
> preempted console_unlock() on this_cpu or recursive printk from
> console_unlock()... and so on.

which is hard to do, given that console_unlock() can schedule with
console_sem locked. so CPU number won't do the trick. unless we will
forbid preemption in console_unlock()... we sort of need to do it.

	-ss

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Steven Rostedt <rostedt@goodmis.org> - 2017-07-03 21:40 +0200
  Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-07-04 07:30 +0200
    Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-07-04 09:00 +0200

csiph-web