From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751917AbcJJBWv (ORCPT ); Sun, 9 Oct 2016 21:22:51 -0400 Received: from mail-pa0-f66.google.com ([209.85.220.66]:36652 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbcJJBWu (ORCPT ); Sun, 9 Oct 2016 21:22:50 -0400 Date: Sat, 8 Oct 2016 03:59:20 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Tejun Heo , Calvin Owens , Thomas Gleixner , Mel Gorman , Steven Rostedt , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv2 6/7] printk: report printk recursion from alt_printk flush Message-ID: <20161007185920.GC486@swordfish> References: <20160930151758.8965-1-sergey.senozhatsky@gmail.com> <20160930151758.8965-7-sergey.senozhatsky@gmail.com> <20161006154112.GJ13369@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161006154112.GJ13369@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 (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. > Instead I would print an error when we missed some messages > because the alternative buffer was not big enough. ok, will do. -ss