linux-kernel - Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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