From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932404AbdDGHQU (ORCPT ); Fri, 7 Apr 2017 03:16:20 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:53237 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932178AbdDGHQG (ORCPT ); Fri, 7 Apr 2017 03:16:06 -0400 Date: Fri, 7 Apr 2017 09:15:58 +0200 From: Pavel Machek To: Sergey Senozhatsky Cc: Jan Kara , "Eric W. Biederman" , Sergey Senozhatsky , Ye Xiaolong , Steven Rostedt , Petr Mladek , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , Greg Kroah-Hartman , Jiri Slaby , Len Brown , linux-kernel@vger.kernel.org, lkp@01.org Subject: Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Message-ID: <20170407071558.GA11792@amd> References: <20170329092511.3958-9-sergey.senozhatsky@gmail.com> <20170330213829.GA21476@inn.lkp.intel.com> <20170331023506.GB3493@jagdpanzerIV.localdomain> <20170331040438.GA366@jagdpanzerIV.localdomain> <20170331063913.GE20961@yexl-desktop> <20170331144730.GA10578@tigerII.localdomain> <87a881v52o.fsf@xmission.com> <20170403093152.GB15168@quack2.suse.cz> <20170406173306.GD10363@amd> <20170407044334.GA487@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20170407044334.GA487@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri 2017-04-07 13:44:40, Sergey Senozhatsky wrote: > Hello, >=20 > On (04/06/17 19:33), Pavel Machek wrote: > > > This patch set gives up part of the printk() reliability for bounded > > > latency (at least unless we detect we are really in trouble) which is= IMHO > > > a good trade-off for lots of users (and others can just turn this fea= ture > > > off). > >=20 > > If they can ever realize they were bitten by this feature. > >=20 > > Can we go for different tradeoff? > >=20 > > In console_unlock(), if you detect too much work, print "Too many > > messages to print, %d bytes delayed" and wake up kernel thread. >=20 > "too many messages" is undefined. console_unlock() can be called from > IRQ handler or with preemtion disabled, or under spin_lock, or under > RCU read lock, etc. etc. By the time we decide to wake up printk_kthread > from console_unlock() it may be already too late. So lets define "too many messages" as 240 characters. We know printk worked rather well for us for more than 20 years. Kernel code is used to printk taking few miliseconds.=20 > besides, this does not really address any of the concerns you have > pointed out in other emails. we might be unable to wake_up printk_kthread > (because there is a misbehaving higher prio process, or because the > scheduler is misbehaving, etc. etc.) so the "emergency mode" is still > here and still requires special handling. Yeah? So you know modified printk() does not work, that's why "emergency mode" exists. Unfortunately, you can't rely on fact that you can detect half-crashed machines by printk levels. You usually can't. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljnPK4ACgkQMOfwapXb+vL2agCfSsFR6ioEoLXFWCYgmYobSF0L VzEAoJhu8k5FGbWEqW/+g44PXoQYkZha =tLMK -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--