From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756686AbcLACSC (ORCPT ); Wed, 30 Nov 2016 21:18:02 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:33730 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753431AbcLACSA (ORCPT ); Wed, 30 Nov 2016 21:18:00 -0500 Date: Thu, 1 Dec 2016 11:18:04 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Andrew Morton , Jan Kara , Tejun Heo , Calvin Owens , Thomas Gleixner , Mel Gorman , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Laura Abbott , Andy Lutomirski , Linus Torvalds , Kees Cook , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Message-ID: <20161201021804.GG12039@jagdpanzerIV> References: <20161027154933.1211-1-sergey.senozhatsky@gmail.com> <20161027154933.1211-7-sergey.senozhatsky@gmail.com> <20161125150113.GJ24103@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161125150113.GJ24103@pathway.suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (11/25/16 16:01), Petr Mladek wrote: > On Fri 2016-10-28 00:49:33, Sergey Senozhatsky wrote: > > We use printk-safe now which makes printk-recursion detection code > > in vprintk_emit() is unreachable. The tricky thing here is that, > ^^ superfluous "is" > > > apart from detecting and reporting printk recursions, that code also > > used to zap_lockc() in case of panic. However, zap_locks() does not > ^ > > s/zap_lockc/zap_locks/ > > > look to be needed anymore: > > > > 1) Since commit 08d78658f393 ("panic: release stale console lock to > > always get the logbuf printed out") panic flushing of `logbuf' to > > console ignores the state of `console_sem' by doing > > panic() > > console_trylock(); > > console_unlock(); > > > > 2) Since commit cf9b1106c81c ("printk/nmi: flush NMI messages on the > > system panic") panic attempts to zap the `logbuf_lock' spin_lock to > > successfully flush nmi messages to `logbuf'. > > Note that the same code is newly used to flush also the printk_safe > per-CPU buffers. It means that logbuf_lock is zapped also when > flushing these new buffers. yes, and I'm a bit skeptical about the whole re-init logbuf_lock, because this lock is just one of possibly many looks that can be 'locked'. the messages are already in per-CPU buffers, so they will present in a core dump file. but it can be done separately, not in this series. > > Basically, it seems that we either already do what zap_locks() used to > > do but in other places or we ignore the state of the lock. May be we > > still would want to do sema_init() in printk_safe_flush_on_panic(), > > just in case. > > Very good question! I would actually suggest to use printk_deferred() > in printk_safe_flush_on_panic() in any context. It will solve the > problems discussed for the 4th patch of this patchset. And it will > solve also this problem. In case of panic, we should first try to > get all messages into the logbuffer so that they are visible in > the crash dump. We try to push them to the console by > console_flush_on_panic() later because it is more risky. > > > Signed-off-by: Sergey Senozhatsky > > If we avoid calling console in printk_safe_flush_on_panic(), > feel free to use: > > Reviewed-by: Petr Mladek ok. thanks. -ss