From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933576AbdDGMKa (ORCPT ); Fri, 7 Apr 2017 08:10:30 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34075 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933242AbdDGMKW (ORCPT ); Fri, 7 Apr 2017 08:10:22 -0400 Date: Fri, 7 Apr 2017 21:10:21 +0900 From: Sergey Senozhatsky To: Pavel Machek Cc: Sergey Senozhatsky , 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: <20170407121021.GA379@jagdpanzerIV.localdomain> References: <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> <20170407071558.GA11792@amd> <20170407074634.GB1091@jagdpanzerIV.localdomain> <20170407081449.GA12859@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170407081449.GA12859@amd> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (04/07/17 10:14), Pavel Machek wrote: [..] > Well. This is what we had for 20 years. I guess it's not just me who is a bit unhappy with printk. ask Peter Zijlstra what's the first word that comes into his mind when we reads "printk" :) [..] > I believe "spend at most 2 seconds in printk(), then print a warning > and offload" is a solution closer to what we had before. a warning here can be very noisy. it's quite common that serial console (`console_seq') is a bit behind the logbuf head (`log_next_seq'). because log_store() can be much faster that call into console drivers. another case is that printk() != console_unlock(). console_sem can be locked by VT, TTY, fbdev, (not to mention that some other CPU might be doing printing), etc. etc. all printk()-s in the meantime will just log_store() messages, so we can have a bunch on pending messsges in logbuf, it's normal. the CPU that owns the console_sem will print all those pending messages from console_unlock() path. the distance between `log_next_seq' and `console_seq' can be much bigger than 2 seconds or 240/320/etc chars. so wrong offloading can leave with nothing valuable in the serial output, even if we would defer it. well, I'm not arguing. just saying that it's not so easy to do everything right here. what we have been thinking about is something like printk-stall detection. we probably (there are some if-s) can detect in printk() that offloading does not work and we must automatically switch to printk_emergency mode. that, in theory, can relax our dependency on printk_emergency_begin/end being in the right place at the right time. need to think more about it. -ss