From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752344AbcJJLCy (ORCPT ); Mon, 10 Oct 2016 07:02:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:32901 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751586AbcJJLCx (ORCPT ); Mon, 10 Oct 2016 07:02:53 -0400 Date: Mon, 10 Oct 2016 13:02:49 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Tejun Heo , Calvin Owens , Thomas Gleixner , Mel Gorman , Steven Rostedt , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv2 6/7] printk: report printk recursion from alt_printk flush Message-ID: <20161010110249.GH23809@pathway.suse.cz> References: <20160930151758.8965-1-sergey.senozhatsky@gmail.com> <20160930151758.8965-7-sergey.senozhatsky@gmail.com> <20161006154112.GJ13369@pathway.suse.cz> <20161007185920.GC486@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161007185920.GC486@swordfish> 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 Sat 2016-10-08 03:59:20, Sergey Senozhatsky wrote: > On (10/06/16 17:41), Petr Mladek wrote: > [..] > > > + if (this_cpu_read(alt_printk_ctx) & ALT_PRINTK_RECURSION_MASK) { > > > + const char *msg = "BUG: recent printk recursion!\n"; > > > + > > > + this_cpu_and(alt_printk_ctx, ~ALT_PRINTK_RECURSION_MASK); > > > + alt_printk_flush_line(msg, strlen(msg)); > > > + } > > > + > > > /* > > > * This is just a paranoid check that nobody has manipulated > > > * the buffer an unexpected way. If we printed something then > > > @@ -290,6 +297,8 @@ static int vprintk_alt(const char *fmt, va_list args) > > > { > > > struct alt_printk_seq_buf *s = this_cpu_ptr(&alt_print_seq); > > > > > > + /* There is only one way to get here -- a printk recursion. */ > > > + this_cpu_or(alt_printk_ctx, ALT_PRINTK_RECURSION_MASK); > > > > Is it really a bug? In most cases, the message that is being printed > > describes a bug. We just allow to print it this alternative way to > > avoid a possible deadlock. IMHO, this might cause a confusion. > > just wanted to preserve the existing behavior, but can drop it. I see. Well, the current code drops the original message if there is a recursion and there is no oops_in_progress. Therefore the warning is the only way to know that a message was lost. But we store the original message in the alternative buffer now. Therefore it is not longer lost. Best Regards, Petr