From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Jan Kara <jack@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>, Tejun Heo <tj@kernel.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
linux-kernel@vger.kernel.org,
Byungchul Park <byungchul.park@lge.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC][PATCH v4 2/2] printk: Skip messages on oops
Date: Thu, 17 Mar 2016 19:56:34 +0900 [thread overview]
Message-ID: <20160317105634.GA10636@swordfish> (raw)
In-Reply-To: <1457964820-4642-3-git-send-email-sergey.senozhatsky@gmail.com>
Hello Jan,
On (03/14/16 23:13), Sergey Senozhatsky wrote:
>
> From: Jan Kara <jack@suse.cz>
>
> When there are too many messages in the kernel printk buffer it can take
> very long to print them to console (especially when using slow serial
> console). This is undesirable during oops so when we encounter oops and
> there are more than 100 messages to print, print just the newest 100
> messages and then the oops message.
I think this patch will introduce a regression, so I'd probably prefer
not to include it now in the series.
the pattern "print something important then panic()" is quite common.
given that other CPUs can printk() a lot before panic_cpu send out
stop_ipi, we can lose the "print something important" part.
...
arch/metag/kernel/cachepart.c: pr_emerg("Potential cache aliasing detected in %s on Thread %d\n",
arch/metag/kernel/cachepart.c- cache_type ? "DCACHE" : "ICACHE", thread_id);
arch/metag/kernel/cachepart.c- pr_warn("Total %s size: %u bytes\n",
arch/metag/kernel/cachepart.c- cache_type ? "DCACHE" : "ICACHE",
arch/metag/kernel/cachepart.c- cache_type ? get_dcache_size()
arch/metag/kernel/cachepart.c- : get_icache_size());
arch/metag/kernel/cachepart.c- pr_warn("Thread %s size: %d bytes\n",
arch/metag/kernel/cachepart.c- cache_type ? "CACHE" : "ICACHE",
arch/metag/kernel/cachepart.c- thread_cache_size);
arch/metag/kernel/cachepart.c- pr_warn("Page Size: %lu bytes\n", PAGE_SIZE);
arch/metag/kernel/cachepart.c- panic("Potential cache aliasing detected");
...
arch/s390/kernel/jump_label.c: pr_emerg("Jump label code mismatch at %pS [%p]\n", ipc, ipc);
arch/s390/kernel/jump_label.c: pr_emerg("Found: %6ph\n", ipc);
arch/s390/kernel/jump_label.c: pr_emerg("Expected: %6ph\n", ipe);
arch/s390/kernel/jump_label.c: pr_emerg("New: %6ph\n", ipn);
arch/s390/kernel/jump_label.c- panic("Corrupted kernel text");
...
another example is hardlockup detector with sysctl_hardlockup_all_cpu_backtrace.
static void watchdog_overflow_callback(...)
{
...
if (is_hardlockup()) {
...
if (sysctl_hardlockup_all_cpu_backtrace &&
!test_and_set_bit(0, &hardlockup_allcpu_dumped))
trigger_allbutself_cpu_backtrace();
nmi_panic(regs, msg);
...
}
...
}
trigger_allbutself_cpu_backtrace() can be much more than 100 lines.
trigger_allbutself_cpu_backtrace() may or may not be implemented via
NMI. for example arch/sparc/kernel/process_64.c
thus, we better avoid skipping any messages when in panic() I think.
-ss
next prev parent reply other threads:[~2016-03-17 10:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 14:13 [RFC][PATCH v4 0/2] printk: Make printk() completely async Sergey Senozhatsky
2016-03-14 14:13 ` [RFC][PATCH v4 1/2] " Sergey Senozhatsky
2016-03-15 10:03 ` Jan Kara
2016-03-15 14:07 ` Sergey Senozhatsky
2016-03-16 5:39 ` Byungchul Park
2016-03-16 6:58 ` Sergey Senozhatsky
2016-03-16 7:30 ` Byungchul Park
2016-03-16 7:56 ` Sergey Senozhatsky
2016-03-16 10:34 ` Byungchul Park
2016-03-17 0:34 ` Sergey Senozhatsky
2016-03-18 5:49 ` Byungchul Park
2016-03-18 7:11 ` Sergey Senozhatsky
2016-03-18 8:23 ` byungchul.park
2016-03-16 7:00 ` Byungchul Park
2016-03-16 7:07 ` Sergey Senozhatsky
2016-03-15 15:58 ` Petr Mladek
2016-03-16 2:01 ` Sergey Senozhatsky
2016-03-16 2:10 ` Byungchul Park
2016-03-16 2:31 ` Sergey Senozhatsky
2016-03-14 14:13 ` [RFC][PATCH v4 2/2] printk: Skip messages on oops Sergey Senozhatsky
2016-03-17 10:56 ` Sergey Senozhatsky [this message]
2016-04-23 19:36 ` [RFC][PATCH v4 0/2] printk: Make printk() completely async Pavel Machek
2016-04-24 5:03 ` 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=20160317105634.GA10636@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=jack@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.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