From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965178AbdCYAUC (ORCPT ); Fri, 24 Mar 2017 20:20:02 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:34028 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932134AbdCYAT4 (ORCPT ); Fri, 24 Mar 2017 20:19:56 -0400 Date: Sat, 25 Mar 2017 09:18:44 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Peter Zijlstra , Steven Rostedt , Andrew Morton , Linus Torvalds , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Message-ID: <20170325001844.GE6356@tigerII.localdomain> References: <20170306124554.828-1-sergey.senozhatsky@gmail.com> <20170322175920.bcltzwega6dts2n4@hirez.programming.kicks-ass.net> <20170323040958.GB2519@jagdpanzerIV.localdomain> <20170323085143.2cpxgtlmhhrvrcbw@hirez.programming.kicks-ass.net> <20170324015936.GA366@jagdpanzerIV.localdomain> <20170324144308.GA12055@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170324144308.GA12055@pathway.suse.cz> 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 (03/24/17 15:43), Petr Mladek wrote: [..] > > we have that thing which we call "old printk" mode, which is not > > really informative. and my proposal is rename "old" mode and use > > "printk rescue" mode instead. because we switch to that mode when > > we are trying to "rescue" kernel logs. so the API can be something > > like > > printk_rescue_on() > > printk_rescue_off() > > Sounds good to me. Slight problem is that off() does not cause > stopping the mode if we are nested. > > Just one more attempt inspired by this: > > printk_emergency_begin() > printk_emergency_end() > > Note that we actually start this mode automatically also > with pr_emerg() message. good. printk_emergency sounds OK to me. [..] > > and we've got everything we need to have such a feedback in > > vprintk_emit(): > > > > a) console is not suspended so console_unlock() can call console drivers > > b) printk_kthread != NULL > > c) we are not in enforced rescue/emergency mode > > d) `log_next_seq' moves forward (always `true', we are in vprintk_emit()) > > e) `console_seq' stands still > > > > so we can have an automatic rescue mode fallback in vprintk_emit(). > > if (a)-(e) are true then we give up on waking up printk_kthread, > > switch to rescue mode and attempt to console_trylock() directly from > > vprintk_emit(). the part that sucks here is that we need to give > > printk_kthread some time to catch up. for instance, if (e) is true > > for the past 50 invocations of vprintk_emit(), IOW: > > > > - we added 50 lines to printk > > - none have been printed on the serial console > > > > then we > > - declare rescue > > - do console_trylock() instead of wake_up() //unless in deferred vprintk_emit() > > I am not sure if we are able to distinguish a flood of messages > from a real emergency situation. that's one of problems. yes. > Well, there is a handful of annotated locations at the moment. > I would start thinking of an automatic detection once we have > more of them and have more data for a good heuristic. so my 'automatic emergency' switch is for another case. when we wake_up() printk_kthread, but it never prints anything. could be caused by a missing printk_emergency annotation, or something else. > I still would like to see the kernel parameter/sysfs knob > that would allow to force the rescue/emergency mode all > the time ;-) sure. -ss