Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932828AbcKVMOi (ORCPT ); Tue, 22 Nov 2016 07:14:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:58194 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932362AbcKVMOh (ORCPT ); Tue, 22 Nov 2016 07:14:37 -0500 Date: Tue, 22 Nov 2016 13:14:33 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Jason Wessel , Daniel Thompson , Peter Zijlstra , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] kdb: Call vkdb_printf() from vprintk_default() only when wanted Message-ID: <20161122121433.GC8220@pathway.suse.cz> References: <1477054235-1624-1-git-send-email-pmladek@suse.com> <1477054235-1624-3-git-send-email-pmladek@suse.com> <20161023132343.GA466@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161023132343.GA466@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 Content-Length: 995 Lines: 26 On Sun 2016-10-23 22:23:43, Sergey Senozhatsky wrote: > On (10/21/16 14:50), Petr Mladek wrote: > [..] > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > index d5e397315473..db73e33811e7 100644 > > --- a/kernel/printk/printk.c > > +++ b/kernel/printk/printk.c > > @@ -1941,7 +1941,9 @@ int vprintk_default(const char *fmt, va_list args) > > int r; > > > > #ifdef CONFIG_KGDB_KDB > > - if (unlikely(kdb_trap_printk)) { > > + /* Allow to pass printk() to kdb but avoid a recursion. */ > > + if (unlikely(kdb_trap_printk && > > + kdb_printf_cpu != smp_processor_id())) { > ^^^^^ > aren't we are in preemptible here? Yeah, I looked on this from one side only. "kdb_printf_cpu" is set with disabled IRQs. Therefore the preemption is disabled if we are in the recursion scenario. But you are right that we might get a false positive if we are preempted in the middle of this check and later scheduled on the CPU that called kdb_vprintf before. Best Regards, Petr