From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756030AbcJFPlV (ORCPT ); Thu, 6 Oct 2016 11:41:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:57809 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755758AbcJFPlO (ORCPT ); Thu, 6 Oct 2016 11:41:14 -0400 Date: Thu, 6 Oct 2016 17:41:12 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: 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: <20161006154112.GJ13369@pathway.suse.cz> References: <20160930151758.8965-1-sergey.senozhatsky@gmail.com> <20160930151758.8965-7-sergey.senozhatsky@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160930151758.8965-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 Sat 2016-10-01 00:17:57, Sergey Senozhatsky wrote: > If we end up executing vprintk_alt() then we have a printk > recursion. Set alt_printk_ctx `ALT_PRINTK_RECURSION_MASK' bit > in vprintk_alt() to indicate that recutsion and report the > "BUG: recent printk recursion!" problem later from > __alt_printk_flush(). > > Example: > > BUG: recent printk recursion! > ------------[ cut here ]------------ > WARNING: CPU: 3 PID: 366 at kernel/printk/printk.c:1803 vprintk_emit+0x139/0x38c > CPU: 3 PID: 366 Comm: bash > Call Trace: > [] dump_stack+0x4d/0x63 > [] __warn+0xb8/0xd3 > [] warn_slowpath_null+0x18/0x1a > [] vprintk_emit+0x139/0x38c > [] vprintk_default+0x18/0x1a > [] vprintk_func+0x65/0x67 > [] printk+0x3e/0x46 > [..] > [] entry_SYSCALL_64_fastpath+0x13/0x94 > ---[ end trace ]--- > > Signed-off-by: Sergey Senozhatsky > --- > kernel/printk/alt_printk.c | 9 +++++++++ > kernel/printk/internal.h | 1 + > 2 files changed, 10 insertions(+) > > diff --git a/kernel/printk/alt_printk.c b/kernel/printk/alt_printk.c > index db0bfc8..0010089 100644 > --- a/kernel/printk/alt_printk.c > +++ b/kernel/printk/alt_printk.c > @@ -150,6 +150,13 @@ static void __alt_printk_flush(struct irq_work *work) > more: > len = atomic_read(&s->len); > > + 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. Instead I would print an error when we missed some messages because the alternative buffer was not big enough. Best Regards, Petr