All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.