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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ