From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753698AbdDJPIr (ORCPT ); Mon, 10 Apr 2017 11:08:47 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36109 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752841AbdDJPI1 (ORCPT ); Mon, 10 Apr 2017 11:08:27 -0400 Date: Tue, 11 Apr 2017 00:08:20 +0900 From: Sergey Senozhatsky To: Petr Mladek , Pavel Machek Cc: Sergey Senozhatsky , Sergey Senozhatsky , Jan Kara , "Eric W. Biederman" , Ye Xiaolong , Steven Rostedt , 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: <20170410150820.GB457@tigerII.localdomain> References: <20170407044334.GA487@jagdpanzerIV.localdomain> <20170407071558.GA11792@amd> <20170407074634.GB1091@jagdpanzerIV.localdomain> <20170407081449.GA12859@amd> <20170407121021.GA379@jagdpanzerIV.localdomain> <20170407124455.GC4756@amd> <20170407151306.GA384@tigerII.localdomain> <20170409101230.GB27363@amd> <20170410045339.GB2793@jagdpanzerIV.localdomain> <20170410115432.GV3452@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170410115432.GV3452@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 (04/10/17 13:54), Petr Mladek wrote: [..] > > > that works with my proposal, but not with yours. Seen it happen many > > > times before. > > > > I see your point, sure. > > I can't completely agree on "that works with my proposal, but not with yours." > > > > on SMP system this would be true only if no other CPU holds the console_sem > > at the time we call printk(). (skipping irrelevant cases when we have suspended > > console or !online CPU and !CON_ANYTIME console). and there is nothing that > > makes "no other CPU holds the console_sem" always true on SMP system at any > > given point in time. so no, "A always works, B never works" is not accurate. > > > > but, once again, I see your point. > > A compromise might be to move the offloading from vprintk_emit() to > console_unlock(). By other words, the printk could always try to > flush some messages to the console. The console might trigger > the offload (wakeup kthread) after few lines yep, that's the proposal. hm, this also should align with one more thing. we briefly discussed it before, and it was on my list, that wake_up(printk_kthread) _eventually_ better be moved to console_unlock() [1] (I also had it in the slides at KS, but I believe we didn't have much time back then). vprintk_emit() is not the only console_lock() caller. user space does console_lock() and console_unlock() calls, and in some cases a user space process can stuck in system call printing kernel messages to a potentially slow console [2]. it can be unpleasant, but far less dramatic than doing console_unlock() from IRQ, or under spin_lock. so it was moved down the list. seems we have one more reason to reshuffle the list and do offloading from console_unlock() from the beginning. will take a look. /* in our "in-house" kernels we do 'async' console_unlock(). not exactly the way it's shown in [1], but quite similar. */ [1] https://marc.info/?l=linux-kernel&m=145750373530161 [2] https://marc.info/?l=linux-kernel&m=145762735308470 -ss From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7634471864758579472==" MIME-Version: 1.0 From: Sergey Senozhatsky To: lkp@lists.01.org Subject: Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage Date: Tue, 11 Apr 2017 00:08:20 +0900 Message-ID: <20170410150820.GB457@tigerII.localdomain> In-Reply-To: <20170410115432.GV3452@pathway.suse.cz> List-Id: --===============7634471864758579472== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On (04/10/17 13:54), Petr Mladek wrote: [..] > > > that works with my proposal, but not with yours. Seen it happen many > > > times before. > > = > > I see your point, sure. > > I can't completely agree on "that works with my proposal, but not with = yours." > > = > > on SMP system this would be true only if no other CPU holds the console= _sem > > at the time we call printk(). (skipping irrelevant cases when we have s= uspended > > console or !online CPU and !CON_ANYTIME console). and there is nothing = that > > makes "no other CPU holds the console_sem" always true on SMP system at= any > > given point in time. so no, "A always works, B never works" is not accu= rate. > > = > > but, once again, I see your point. > = > A compromise might be to move the offloading from vprintk_emit() to > console_unlock(). By other words, the printk could always try to > flush some messages to the console. The console might trigger > the offload (wakeup kthread) after few lines yep, that's the proposal. hm, this also should align with one more thing. we briefly discussed it before, and it was on my list, that wake_up(printk_kthread) _eventually_ better be moved to console_unlock() [1] (I also had it in the slides at KS, but I believe we didn't have much time back then). vprintk_emit() is not the only console_lock() caller. user space does console_lock() and console_unlock() calls, and in some cases a user space process can stuck in system call printing kernel messages to a potentially slow console [2]. it can be unpleasant, but far less dramatic than doing console_unlock() from IRQ, or under spin_lock. so it was moved down the list. seems we have one more reason to reshuffle the list and do offloading from console_unlock() from the beginning. will take a look. /* in our "in-house" kernels we do 'async' console_unlock(). not exactly the way it's shown in [1], but quite similar. */ [1] https://marc.info/?l=3Dlinux-kernel&m=3D145750373530161 [2] https://marc.info/?l=3Dlinux-kernel&m=3D145762735308470 -ss --===============7634471864758579472==--