From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933591AbdDGMG7 (ORCPT ); Fri, 7 Apr 2017 08:06:59 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:60357 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933430AbdDGMGv (ORCPT ); Fri, 7 Apr 2017 08:06:51 -0400 Date: Fri, 7 Apr 2017 14:06:42 +0200 From: Pavel Machek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Steven Rostedt , Petr Mladek , Jan Kara , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Len Brown , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv2 2/8] printk: introduce printing kernel thread Message-ID: <20170407120642.GB4756@amd> References: <20170329092511.3958-1-sergey.senozhatsky@gmail.com> <20170329092511.3958-3-sergey.senozhatsky@gmail.com> <20170406171430.GB10363@amd> <20170407051244.GB487@jagdpanzerIV.localdomain> <20170407072143.GB11792@amd> <20170407081546.GD1091@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <20170407081546.GD1091@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 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > On (04/07/17 09:21), Pavel Machek wrote: > > > spin_dump() and trigger_all_cpu_backtrace() result in a bunch of > > > additional printk()-s so CPU0 has even more job to do in console_unlo= ck(), > > > while it still holds the contended spin_lock. and so on; there are > > > many other examples. > > >=20 > > > so should we declare a "we can spend only 2 seconds in direct printk() > > > and then must offload printing" rule? I don't think it's much better > > > than a simpler "we always offload, as long as we think it's safe". > >=20 > > I believe we should do the 2 seconds rule. It allows us to print "some > > messages delayed" message, so at least whoever is trying to debug the > > crash will have the hints that he needs to look at the printk system. >=20 > do you mean panic()? in panic() we call console_flush_on_panic(), > which immediately outputs all pending logbuf messages. printk() > offloading does not happen there. Not panic(). I have seen many crashes where we had printk(KERN_ERR) and then hard hang. And the printk() was really important for debugging. > > "we always offload, as long as we think it's safe" rule does not > > really work, as printk() can not detect if it is safe or not. >=20 > but "2 seconds" rule has that "as long as we think it's safe" string > attached as well. just because we do offloading. which is sometimes > un-safe. so regardless the timeout value (0 seconds or 2 seconds) we > still need some sort of a hint from the path that issues printk() > because that path (panic, kexec, sysrq, etc.) knows for sure when > things are abnormal. printk() is pretty clueless in this regard. > /* well, I still think that EMERG loglevel thing is not completely > broken. */ Well, at least with my solution you know there are messages that were not printed. Yes, you'd still want to switch printk_now() for stuff like panic(). But if you get it wrong (and you will), at least you will see the "something is missing here" message in the log.=20 Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljngNIACgkQMOfwapXb+vLyJQCfZoKgn/tmMWLdMfFzQP7WVlUV ts8AnRmyJzme/hpIdsa+bzcUeaKbh5tW =Jnl6 -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye--