Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp1617832imp; Fri, 22 Feb 2019 07:16:16 -0800 (PST) X-Google-Smtp-Source: AHgI3IYII2YrBX9J5JX2Oqpr4go36Ebt8ZibAWZN053h+QpjDTuugJ2CTZOW5QGJr3jVFmZTBKnL X-Received: by 2002:a17:902:e01:: with SMTP id 1mr4549879plw.251.1550848576707; Fri, 22 Feb 2019 07:16:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550848576; cv=none; d=google.com; s=arc-20160816; b=syiZF84jH/65+M9QY5dHvc0UFlquqrEPMVVbd0xBi9s191bOtf0uJGE/Rzltj+9sRW yaYjI44WPhdiWMOfU/P3wgLc4/OuX3Y6AQFUfHNYs56z0hRqte7M6F64J7iAocKQDQUK b21GP2btk5oJT3NzJSKWOjWbTkj9CdE6Us5bX2HF6EwiSfAkAEHNv86wvQo2sYURwyDZ qVDlQoPveili0no3yjyIFtZnI8IaoTfWVzeRUHQcn1NpTEkKAPWm6WaHhUY2Za3C6VC1 vpjSL5XwzwkOyhmCIegIYwameyjzX9LBE6DuzWa7W2tLzyyf7Zk+edE7y6BlxH0sBO49 ssLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=YA4hH5QNHPDDYQbe6vSslTc6ReThOOaNOg2yxpCp1ZY=; b=e7ClHhEapkCBJnd3bT3HsaazG/vKUVORMqruxp4vJPVhGrbjlfMAoTOBR7LD5GBjqk WDac6TkVimWV4DJPr40hawLe90KNiCcmO870qPRdeZP8cDw4hQ1/Vj+V2nY5V9N3I5eP WhyPsUWK/o7V6iLBzFxb2eVduZ/73hiV1sm2uGAxXNeUJ35seS9a0V7kZWI4dLpu617Q TuuSU3/ZKK8li06khxw28FdynoMCux2y5Ahxi4XHlT7WYC0+cD1IDTAGBfUNCjx4XDYZ +RmWySywXvisWgygGQFfZCsVMmPBNlZixwrmmsCuf9hYX99aEgrmSzKNEkDSZ/i/U2Zj qk+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b6si792334pfd.168.2019.02.22.07.16.01; Fri, 22 Feb 2019 07:16:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726656AbfBVPP2 (ORCPT + 99 others); Fri, 22 Feb 2019 10:15:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:40142 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725892AbfBVPP2 (ORCPT ); Fri, 22 Feb 2019 10:15:28 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id B25F2AEB3; Fri, 22 Feb 2019 15:15:26 +0000 (UTC) Date: Fri, 22 Feb 2019 16:15:24 +0100 From: Petr Mladek To: John Ogness Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Sergey Senozhatsky , Steven Rostedt , Daniel Wang , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , Alan Cox , Jiri Slaby , Peter Feiner , linux-serial@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC PATCH v1 11/25] printk_safe: remove printk safe code Message-ID: <20190222151524.2iosxbcpn5bb4cbq@pathway.suse.cz> References: <20190212143003.48446-1-john.ogness@linutronix.de> <20190212143003.48446-12-john.ogness@linutronix.de> <20190222103732.zkcvjijtdcfu4vbt@pathway.suse.cz> <87h8cwymcr.fsf@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h8cwymcr.fsf@linutronix.de> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2019-02-22 14:38:28, John Ogness wrote: > On 2019-02-22, Petr Mladek wrote: > >> diff --git a/lib/nmi_backtrace.c b/lib/nmi_backtrace.c > >> index 15ca78e1c7d4..77bf84987cda 100644 > >> --- a/lib/nmi_backtrace.c > >> +++ b/lib/nmi_backtrace.c > >> @@ -75,12 +75,6 @@ void nmi_trigger_cpumask_backtrace(const cpumask_t *mask, > >> touch_softlockup_watchdog(); > >> } > >> > >> - /* > >> - * Force flush any remote buffers that might be stuck in IRQ context > >> - * and therefore could not run their irq_work. > >> - */ > >> - printk_safe_flush(); > >> - > >> clear_bit_unlock(0, &backtrace_flag); > >> put_cpu(); > >> } > > > > This reminds me that we need to add back the locking that was > > removed in the commit 03fc7f9c99c1e7ae2925d45 ("printk/nmi: > > Prevent deadlock when accessing the main log buffer in NMI"). > > No, that commit is needed. You cannot have NMIs waiting on other CPUs. It sounds weird. But it is safe to use a lock when it is used only in the NMI context. The lock has always been there. For example, I found it in the commit 1fb9d6ad2766a1dd70 ("nmi_watchdog: Add new, generic implementation, using perf events") from v2.6.36. It could get removed only because we switched to the per-CPU buffers. > > Otherwise, backtraces from different CPUs would get mixed. > > A later patch (#17) adds CPU IDs to the printk messages so that this > isn't a problem. (That patch is actually obsolete now because Sergey has > already merged work for linux-next that includes this information.) No this is not enough. First, the CPU-ids were primary added for kernel testers (0-day robot, kernel-ci, syzcaller). It is not enabled by default. It is not handled by kmsg interface. Also sorting the messages is not much user friendly. It should be the last resort when no other solution is possible. Best Regards, Petr