From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758308AbcLACek (ORCPT ); Wed, 30 Nov 2016 21:34:40 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:36213 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757927AbcLACei (ORCPT ); Wed, 30 Nov 2016 21:34:38 -0500 Date: Thu, 1 Dec 2016 11:34:42 +0900 From: Sergey Senozhatsky To: Peter Zijlstra Cc: Petr Mladek , Sergey Senozhatsky , Andrew Morton , Jan Kara , Tejun Heo , Calvin Owens , Thomas Gleixner , Mel Gorman , Steven Rostedt , Ingo Molnar , 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: <20161201023442.GH12039@jagdpanzerIV> References: <20161027154933.1211-1-sergey.senozhatsky@gmail.com> <20161027154933.1211-7-sergey.senozhatsky@gmail.com> <20161125150113.GJ24103@pathway.suse.cz> <20161125151724.GO3092@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161125151724.GO3092@twins.programming.kicks-ass.net> 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:17), Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:01:13PM +0100, Petr Mladek wrote: > > On Fri 2016-10-28 00:49:33, Sergey Senozhatsky wrote: > > > 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. > > > > Note that (raw_)spin_lock_init() as done here and in > printk_nmi_flush_on_panic() can wreck the lock state and doesn't ensure > a subsequent spin_lock() of said lock will actually work. > > The very best solution is to simply ignore the lock in panic situations > rather than trying to wreck it. do you mean that we can enterily drop the spin_lock_init()? or is there something else? spin_lock_init() either does not improve anything or let us to, at least, move the messages from per-CPU buffers to the logbuf. so it's not like it does some damage, and it can help sometimes. though I agree that a) we have the messages in the memory already and b) logbuf_lock is not the one&only troubling lock. -ss