From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755184AbcKYPOz (ORCPT ); Fri, 25 Nov 2016 10:14:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:46120 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755296AbcKYPNv (ORCPT ); Fri, 25 Nov 2016 10:13:51 -0500 Date: Fri, 25 Nov 2016 16:01:13 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: 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: <20161125150113.GJ24103@pathway.suse.cz> References: <20161027154933.1211-1-sergey.senozhatsky@gmail.com> <20161027154933.1211-7-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161027154933.1211-7-sergey.senozhatsky@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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 Best Regards, Petr