Received: by 10.223.176.5 with SMTP id f5csp154014wra; Fri, 26 Jan 2018 19:58:38 -0800 (PST) X-Google-Smtp-Source: AH8x2250bWIkwJ5x3HP5bRGiljQMkx4sHtJWHB5B/q3aNdvnUGU6PTnelcKKldozO2ddl9Xd3giy X-Received: by 10.99.126.73 with SMTP id o9mr8315597pgn.429.1517025518393; Fri, 26 Jan 2018 19:58:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517025518; cv=none; d=google.com; s=arc-20160816; b=D76Ru9H6PryY9DBgrcDQwJSjQl6IA5/LFxLLgLLYzWsD6YXRrNm591igSkANujcccz 77gNM3OOEBdPztVrbaeHbfsseeSfBL4Nta4yM7pPVaEctrhFS43XQsJ/pUZ+OOaFxSb0 GT6EWVGhz4Sxo3TKquri1XAEGvirY+ELDa2wdslRb6F8M9uj6boVPolTrZ/FUeUKG8E4 fnkmCPw/+y9IoDz5FBdvCSfp1xJTixACftMylwIZAF2GKJid24oVcwPNszFZIdbP7nLM 3SCounWi6Gs/fL5ebFCLMjp4tXc57yRvNLdPFc1vtmoZIX4LD1iln0h6BJv6gEfqQGfE WB2A== 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:arc-authentication-results; bh=rsDa+LkrqOY4gQpd7571sm/8wb7vAA6cIMgnoAVd/4Q=; b=CaftvpScIt4d1udFcp0GdmvRgVvApEoaCdya1DEWyy4tbT7SdeaVwCswYI7bIi6T4h 1r9B06CePBf5ll9ZSQWDhT10fg1wkgJawiEQlPsBiD8pRTrMfzp839W0v23CbXCkbwAr mYi3eijpZ/vrE5z46m2LZzCe4lS379I4EmdGYTzl88xlbZAtJAkdVd4BU5Wx+R+xKgDE yFSHZSt8n8g+JskMvdpYkpR8zKHXxk/Ne6O5kovyT1mb3xrK5HblHCI1kXzNu2UTW6iN KSIRBMcHfe2Rw2yyZ9Md4G8fZ6T+1JzU2FMLQHqAgLS4RV16tISoSqODKaetNXIxSnvo LUJA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 86si7427477pfp.347.2018.01.26.19.58.14; Fri, 26 Jan 2018 19:58:38 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751795AbeA0D5l (ORCPT + 99 others); Fri, 26 Jan 2018 22:57:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46954 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbeA0D5k (ORCPT ); Fri, 26 Jan 2018 22:57:40 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0DA791752BD; Sat, 27 Jan 2018 03:57:40 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-53.pek2.redhat.com [10.72.12.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E62A2BC587; Sat, 27 Jan 2018 03:57:36 +0000 (UTC) Date: Sat, 27 Jan 2018 11:57:32 +0800 From: Dave Young To: Petr Mladek Cc: Steven Rostedt , Andi Kleen , sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, kexec@lists.infradead.org Subject: Re: [PATCH] print kdump kernel loaded status in stack dump Message-ID: <20180127035732.GB26591@dhcp-128-65.nay.redhat.com> References: <20180117045057.GA4994@dhcp-128-65.nay.redhat.com> <878tcvt592.fsf@linux.intel.com> <20180118135704.62d0f79f@gandalf.local.home> <20180119044719.GA3985@dhcp-128-65.nay.redhat.com> <20180126073724.GA27220@dhcp-128-65.nay.redhat.com> <20180126121757.kec5ecxfxf5fprbi@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180126121757.kec5ecxfxf5fprbi@pathway.suse.cz> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Sat, 27 Jan 2018 03:57:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/18 at 01:17pm, Petr Mladek wrote: > On Fri 2018-01-26 15:37:24, Dave Young wrote: > > On 01/19/18 at 12:47pm, Dave Young wrote: > > > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > > > On Thu, 18 Jan 2018 10:02:17 -0800 > > > > Andi Kleen wrote: > > > > > > > > > Dave Young writes: > > > > > > printk("%sHardware name: %s\n", > > > > > > log_lvl, dump_stack_arch_desc_str); > > > > > > + if (kexec_crash_loaded()) > > > > > > + printk("%skdump kernel loaded\n", log_lvl); > > > > > > > > > > Oops/warnings are getting longer and longer, often scrolling away > > > > > from the screen, and if the kernel crashes backscroll does not work > > > > > anymore, so precious information is lost. > > > > > > > > > > Can you merge it with some other line? > > > > > > > > > > Just a [KDUMP] or so somewhere should be good enough. > > > > > > > > Or perhaps we should add it as a TAINT. Not all taints are bad. > > > > > > Hmm, I also thought about this before but It sounds like not match the > > > "tainted" meaning with the assumption that it is bad :( > > > > > > Maybe it would be better to do like Andi said, but print a better word > > > than "KDUMP", eg. "Kdumpable" sounds better. If this is fine I can > > > repost the patch. > > > > I have been not available recently, sorry for late about the update, > > rethinking about this, it is looks good to use "[KDUMP]". Also for > > the tainted flags, I tried but it is not what we want since kdump kernel > > can be unloaded, this is not like "tainted" which can only be added and > > it can not be removed. > > > > How about below version? > > --- > > > > It is useful to print kdump kernel loaded status in dump_stack() > > especially when panic happens so that we can differentiate > > kdump kernel early hang and a normal panic in a bug report. > > > > Signed-off-by: Dave Young > > --- > > [v1 -> v2] merge the status in other line as Andi Kleen suggested > > kernel/printk/printk.c | 3 +++ > > --- linux.orig/kernel/printk/printk.c > > +++ linux/kernel/printk/printk.c > > @@ -48,6 +48,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -3118,9 +3119,11 @@ void __init dump_stack_set_arch_desc(con > > */ > > void dump_stack_print_info(const char *log_lvl) > > { > > - printk("%sCPU: %d PID: %d Comm: %.20s %s %s %.*s\n", > > + printk("%sCPU: %d PID: %d Comm: %.20s %s %s %s %.*s\n", > > log_lvl, raw_smp_processor_id(), current->pid, current->comm, > > - print_tainted(), init_utsname()->release, > > + print_tainted(), > > + kexec_crash_loaded() ? "[KDUMP]" : "", > > I am afraid that people might be confused what that exactly means. > For example, if I would wonder if it was already running the crashdump > kernel. > > And two small nits. It always prints the extra space. It does not fit > the style of the line. > > What about the following? > > printk("%sCPU: %d PID: %d Comm: %.20s %s%s %s %.*s\n", > log_lvl, raw_smp_processor_id(), current->pid, current->comm, > kexec_crash_loaded() ? "Kdump: loaded " : "", > print_tainted(), > init_utsname()->release, > (int)strcspn(init_utsname()->version, " "), > init_utsname()->version); > > It would produce something like: > > CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 4.14.0-4-default+ #670 That should be a better version, thanks for catching the extra whitespace. Let me do a test and send it out as V2 separately. > > > Best Regards, > Petr