From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: Petr Mladek <pmladek@suse.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Viresh Kumar <viresh.kumar@linaro.org>, Tejun Heo <tj@kernel.org>,
Jiri Kosina <jkosina@suse.com>
Subject: [Ksummit-discuss] [TECH TOPIC] asynchronous printk
Date: Tue, 19 Jul 2016 12:47:17 +0900 [thread overview]
Message-ID: <20160719034717.GA24189@swordfish> (raw)
Hello,
Wondering if anyone will be interested in printk-related topics
(or we can handle it in the mailing list).
What I have on my list is:
- synchronous printk()
printk() prints messages from kernel printk buffer until the buffer
is empty. When serial console is attached, printing is slow and thus
other CPUs in the system have plenty of time to append new messages to
the buffer while one CPU is printing. Thus the CPU can spend unbounded
amount of time doing printing in console_unlock(). This is especially
serious problem if the printk() calling console_unlock() was called with
interrupts disabled, or from IRQ, or from spin_lock protected section
(if the spinlock is contended), etc. etc. IOW, printk() is quite dangerous
function to call in some cases, it can cause different types of lockups
(soft, hard, spinlock), stalls and so on.
we have some progress on this side. printk() can offload printing from
sensitive and unsafe contexts to a schedulable printk_kthread context (a
special purpose printing kthread).
but "The whole idea remains worrisome", per Andrew :)
- synchronous console_unlock()
there are many places that need to lock and unlock console semaphore
for purposes other than flushing the log_buf. apart from 'in-kernel'
users (e.g. video, etc.) some of those console_lock/console_unlock
are done by user-space apps in system calls. examples:
= open /dev/ttyX
console_unlock()
...
console_lock()
tty_open()
console_device()
chrdev_open()
SyS_open()
= cat /proc/consoles
console_unlock()
c_stop()
...
console_lock()
c_start()
seq_read()
proc_reg_read()
vfs_read()
SyS_read()
= and so on.
so user-space apps can print kernel messages. which is not really nice,
I think. I have a patch that makes console_unlock() async as well; but
we still have console_lock() that is sync.
thus
- console semaphore
not every console_lock() caller has an intention to modify console driver
state, or console drivers list. so we probably can start distinguish READ
console drivers list access and WRITE access.
- KERN_CONT handling
the comment for KERN_CONT in include/linux/kern_levels.h suggests that
/*
* Annotation for a "continued" line of log printout (only done after a
* line that had no enclosing \n). Only to be used by core/arch code
* during early bootup (a continued line is not SMP-safe otherwise).
*/
#define KERN_CONT→ ""
the thing is that people want cont lines in SMP-mode, and people do
use KERN_CONT in SMP mode. e.g. cgroups, ACPI, etc.
internally printk maintains a single cont buffer and, thus, there are
numerous if-s and else-s to cope with the fact that it can be used in
SMP-mode. so the question is -- is it the right time to make KERN_CONT
SMP-safe?
may be we can move cont buffers into per-CPU and add a new API for
cont printing -- pr_cont_begin()/pr_cont_end(). so the usage will be
something like this:
+ pr_cont_begin(); /* preempt disable */
for (...)
pr_cont("foo .... " .....);
+ pr_cont_end(); /* preempt enable */
Petr Mladek has another idea:
http://marc.info/?l=linux-kernel&m=146860197621876
The list of potential attendees
(not in any particular order, most likely incomplete)
Jan Kara
Petr Mladek
Andrew Morton
Jiri Kosina
Tejun Heo
Hannes Reinecke
Viresh Kumar
Steven Rostedt
Sergey Senozhatsky
-ss
next reply other threads:[~2016-07-19 3:47 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 3:47 Sergey Senozhatsky [this message]
2016-07-19 3:56 ` [Ksummit-discuss] [TECH TOPIC] asynchronous printk Viresh Kumar
2016-07-19 6:17 ` Hannes Reinecke
2016-07-19 6:49 ` Josh Triplett
2016-07-19 7:02 ` Hannes Reinecke
2016-07-19 7:11 ` Geert Uytterhoeven
2016-07-20 6:02 ` Jan Kara
2016-07-20 22:54 ` Josh Triplett
2016-07-21 0:46 ` Sergey Senozhatsky
2016-07-21 1:12 ` Josh Triplett
2016-07-19 7:33 ` Sergey Senozhatsky
2016-07-19 7:38 ` Hannes Reinecke
2016-07-19 7:46 ` Sergey Senozhatsky
2016-07-19 8:02 ` Hannes Reinecke
2016-07-19 8:23 ` Sergey Senozhatsky
2016-07-21 10:36 ` David Woodhouse
2016-07-21 12:31 ` Jan Kara
2016-07-28 2:55 ` Steven Rostedt
2016-07-20 6:09 ` Jan Kara
2016-07-19 7:46 ` Christian Borntraeger
2016-07-19 7:53 ` Christian Borntraeger
2016-07-19 13:55 ` Jan Kara
2016-07-28 2:59 ` Steven Rostedt
2016-07-28 4:12 ` Sergey Senozhatsky
2016-07-28 13:02 ` Steven Rostedt
2016-07-20 3:35 ` Wangnan (F)
2016-07-21 1:16 ` Andy Lutomirski
2016-07-21 1:52 ` Wangnan (F)
2016-07-21 5:59 ` Hannes Reinecke
2016-07-21 10:31 ` David Woodhouse
2016-07-21 11:19 ` Josh Triplett
2016-07-21 11:59 ` David Woodhouse
2016-07-21 14:21 ` Josh Triplett
2016-07-21 14:40 ` David Woodhouse
2016-07-28 3:05 ` Steven Rostedt
2016-08-02 11:59 ` Petr Mladek
2016-07-21 15:05 ` Andy Lutomirski
2016-07-26 14:40 ` David Woodhouse
2016-07-26 15:44 ` Benjamin Herrenschmidt
2016-07-26 21:00 ` Andy Lutomirski
2016-07-27 0:03 ` David Woodhouse
2016-07-27 1:16 ` Sergey Senozhatsky
2016-07-21 10:28 ` David Woodhouse
2016-07-19 14:45 ` James Bottomley
2016-07-19 14:55 ` Sergey Senozhatsky
2016-07-19 17:58 ` James Bottomley
2016-07-19 18:24 ` Viresh Kumar
2016-07-20 2:08 ` Sergey Senozhatsky
2016-07-20 6:14 ` Jan Kara
2016-09-21 4:41 ` Sergey Senozhatsky
2016-10-31 6:54 ` Sergey Senozhatsky
2016-10-31 13:56 ` Theodore Ts'o
2016-10-31 13:59 ` Jiri Kosina
2016-10-31 14:56 ` [Ksummit-discuss] [TECH TOPIC] printk considered harmful (was: [TECH TOPIC] asynchronous printk) Sergey Senozhatsky
2016-10-31 16:18 ` Theodore Ts'o
2016-10-31 18:21 ` Sergey Senozhatsky
2016-10-31 18:26 ` [Ksummit-discuss] [TECH TOPIC] printk considered harmful Hannes Reinecke
2016-10-31 20:28 ` [Ksummit-discuss] [TECH TOPIC] printk considered harmful (was: [TECH TOPIC] asynchronous printk) Jan Kara
2016-11-01 12:27 ` [Ksummit-discuss] [TECH TOPIC] printk considered harmful Hannes Reinecke
2016-11-01 17:50 ` [Ksummit-discuss] [TECH TOPIC] printk considered harmful (was: [TECH TOPIC] asynchronous printk) Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160719034717.GA24189@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=jkosina@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pmladek@suse.com \
--cc=tj@kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).