[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160322081555.GC4459@quack.suse.cz>
Date: Tue, 22 Mar 2016 09:15:55 +0100
From: Jan Kara <jack@...e.cz>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Jan Kara <jack@...e.cz>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
Tejun Heo <tj@...nel.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-kernel@...r.kernel.org,
Byungchul Park <byungchul.park@....com>
Subject: Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async
On Tue 22-03-16 16:57:38, Sergey Senozhatsky wrote:
> : 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
>
> on a large enough system trigger_allbutself_cpu_backtrace() can easily be more
> than 100 lines, and trigger_allbutself_cpu_backtrace() may not be able to print
> the backtraces to console (for example this hardlockuped CPU owns the console_sem)
> before CPU declares oops_in_progress in nmi_panic()->panic().
OK, makes sense. We'd probably need more clever logic in detecting when to
skip. Let's drop it for now and revisit it later if it is an issue. Thanks
for explanation.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists