From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>, Pavel Machek <pavel@ucw.cz>
Cc: Jan Kara <jack@suse.cz>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ye Xiaolong <xiaolong.ye@intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>, Len Brown <len.brown@intel.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage
Date: Thu, 13 Apr 2017 17:19:55 +0900 [thread overview]
Message-ID: <20170413081955.GA424@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <20170413055047.GB13708@jagdpanzerIV.localdomain>
On (04/13/17 14:50), Sergey Senozhatsky wrote:
[..]
> On (04/12/17 01:19), Sergey Senozhatsky wrote:
> [..]
> > it does offloading after X printed lines by the same process.
> > if we reschedule, then the counter resets. which is probably OK,
> > we don't really want any process, except for printk_kthread, to
> > stay in console_unlock() forever.
>
> may be this can be changed. we don't want even printk_kthread to keep
> console_sem locked for too long, because other process that might want
> to lock console_sem have to sleep in TASK_UNINTERRUPTIBLE as long as
> printing thread has pending messages to print. so may be the rule can
> be "every process prints up to `atomic_print_limit' lines and then
> offloads printing - wake_up()s printk_kthread and up()s console_sem".
> some other process (printk_kthread or a process from console_sem wait
> list, let them compete for console_sem) will eventually down()
> console_sem and print the next `atomic_print_limit' lines, while
> current process will have a chance to return from console_unlock() and
> do something else.
something like this, perhaps.
static inline bool console_offload_printing(void)
{
static struct task_struct *printing_task;
static unsigned long lines_printed;
static bool did_wakeup;
if (!atomic_print_limit || !printk_kthread_enabled())
return false;
/* We rescheduled - reset the counters. */
if (printing_task != current) {
did_wakeup = false;
lines_printed = 0;
printing_task = current;
return false;
}
/*
* Don't reset the counter, let CPU overrun the limit.
* The idea is that
*
* a) woken up printk_kthread (if succeeded)
* or
* b) concurrent printk from another CPU (if any)
*
* will change `printing_task' and reset the counter.
* If neither a) nor b) happens - we continue printing from
* current process. Which is bad and can be risky, but we can't
* wake_up() printk_kthread, so things already don't look normal.
*/
lines_printed++;
if (lines_printed < atomic_print_limit)
return false;
if (current == printk_kthread) {
/*
* Reset the counter, just in case if printk_kthread is the
* only process left that would down() console_sem.
*/
lines_printed = 0;
return true;
}
/*
* A trivial emergency enforcement - give up on printk_kthread if
* we can't wake it up. This assumes that `atomic_print_limit' is
* large enough.
*/
if (lines_printed > 2 * (unsigned long long)atomic_print_limit) {
printk_enforce_emergency = true;
pr_crit("Declaring printk emergency mode.\n");
return false;
}
/*
* Must be executed in 'printk_safe' context. Call into the
* scheduler just once, in case if it backfires on us with
* warnings and backtraces.
*/
if (!did_wakeup) {
did_wakeup = true;
wake_up_process(printk_kthread);
}
return true;
}
-ss
next prev parent reply other threads:[~2017-04-13 8:19 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 9:25 [RFC][PATCHv2 0/8] printk: introduce printing kernel thread Sergey Senozhatsky
2017-03-29 9:25 ` [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu Sergey Senozhatsky
2017-03-31 13:09 ` Petr Mladek
2017-03-31 13:33 ` Peter Zijlstra
2017-04-03 11:23 ` Sergey Senozhatsky
2017-04-03 12:43 ` Petr Mladek
2017-03-29 9:25 ` [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Sergey Senozhatsky
2017-04-04 9:01 ` Petr Mladek
2017-04-04 9:36 ` Sergey Senozhatsky
2017-04-06 17:14 ` Pavel Machek
2017-04-07 5:12 ` Sergey Senozhatsky
2017-04-07 7:21 ` Pavel Machek
2017-04-07 8:15 ` Sergey Senozhatsky
2017-04-07 12:06 ` Pavel Machek
2017-03-29 9:25 ` [RFC][PATCHv2 3/8] printk: offload printing from wake_up_klogd_work_func() Sergey Senozhatsky
2017-03-31 14:56 ` Petr Mladek
2017-04-04 16:15 ` Sergey Senozhatsky
2017-03-29 9:25 ` [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Sergey Senozhatsky
2017-03-31 15:06 ` Petr Mladek
2017-04-06 17:20 ` Pavel Machek
2017-04-09 10:59 ` Andreas Mohr
2017-04-10 12:20 ` Petr Mladek
2017-04-10 14:38 ` Sergey Senozhatsky
2017-03-29 9:25 ` [RFC][PATCHv2 5/8] sysrq: " Sergey Senozhatsky
2017-03-31 15:37 ` Petr Mladek
2017-04-01 0:04 ` Sergey Senozhatsky
2017-03-29 9:25 ` [RFC][PATCHv2 6/8] kexec: " Sergey Senozhatsky
2017-03-31 15:39 ` Petr Mladek
2017-03-29 9:25 ` [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter Sergey Senozhatsky
2017-04-03 15:29 ` Petr Mladek
2017-04-04 8:29 ` Sergey Senozhatsky
2017-03-29 9:25 ` [RFC][PATCHv2 8/8] printk: enable printk offloading Sergey Senozhatsky
2017-03-30 21:38 ` [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage kernel test robot
2017-03-31 2:35 ` Sergey Senozhatsky
2017-03-31 4:04 ` Sergey Senozhatsky
2017-03-31 6:39 ` Ye Xiaolong
2017-03-31 14:47 ` Sergey Senozhatsky
2017-03-31 15:28 ` Eric W. Biederman
2017-04-03 9:31 ` Jan Kara
2017-04-03 10:06 ` Petr Mladek
2017-04-06 17:33 ` Pavel Machek
2017-04-07 4:44 ` Sergey Senozhatsky
2017-04-07 7:15 ` Pavel Machek
2017-04-07 7:46 ` Sergey Senozhatsky
2017-04-07 8:14 ` Pavel Machek
2017-04-07 12:10 ` Sergey Senozhatsky
2017-04-07 12:44 ` Pavel Machek
2017-04-07 14:40 ` Steven Rostedt
2017-05-08 6:37 ` Sergey Senozhatsky
2017-05-17 13:13 ` Petr Mladek
2017-04-07 15:13 ` Sergey Senozhatsky
2017-04-07 15:23 ` Peter Zijlstra
2017-04-07 15:40 ` Sergey Senozhatsky
2017-04-09 18:21 ` Eric W. Biederman
2017-04-10 4:46 ` Sergey Senozhatsky
2017-04-09 10:12 ` Pavel Machek
2017-04-10 4:53 ` Sergey Senozhatsky
2017-04-10 11:54 ` Petr Mladek
2017-04-10 15:08 ` Sergey Senozhatsky
2017-04-10 18:48 ` Pavel Machek
2017-04-11 1:46 ` Sergey Senozhatsky
2017-04-11 16:19 ` Sergey Senozhatsky
2017-04-12 18:43 ` Pavel Machek
2017-04-13 4:34 ` Sergey Senozhatsky
2017-04-13 5:50 ` Sergey Senozhatsky
2017-04-13 8:19 ` Sergey Senozhatsky [this message]
2017-04-13 14:03 ` Petr Mladek
2017-04-14 4:42 ` Sergey Senozhatsky
2017-04-07 14:29 ` Steven Rostedt
2017-04-09 9:57 ` Pavel Machek
2017-04-03 10:51 ` Sergey Senozhatsky
2017-04-05 7:29 ` Ye Xiaolong
2017-04-05 8:40 ` Sergey Senozhatsky
2017-04-03 15:42 ` [RFC][PATCHv2 8/8] printk: enable printk offloading Petr Mladek
2017-04-04 13:20 ` 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=20170413081955.GA424@jagdpanzerIV.localdomain \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jslaby@suse.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=xiaolong.ye@intel.com \
/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