Received: by 10.223.176.46 with SMTP id f43csp623334wra; Fri, 26 Jan 2018 04:23:32 -0800 (PST) X-Google-Smtp-Source: AH8x224nA5UJ8EOKT1j9Wm6e3IxMfMrpEWL06bTY8IN5tJmGooTVATjWVqlyi7POUd9VKpNbTocw X-Received: by 10.98.134.206 with SMTP id x197mr7362215pfd.82.1516969412079; Fri, 26 Jan 2018 04:23:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516969412; cv=none; d=google.com; s=arc-20160816; b=nJWWaLYrzC92S8V+oYh3Fw/nml+fQr7YQHKZj3egWm2g18xmeiBbYEzhq3Ryqv+JDo BQEWqldc0WbKaTifnpvCtKe4Xxk6qkc55sLhC/JyJxg2SgnmKIzw9/EH/lhEF+Extvoj TSl+uLlB/ob/PZ9MOhKmB6adait73GYxuOmwQtJ257L7DC0k4gqWuTn7LcVCg3VOzlaK EwK83m9e7UKCrQ87mh32ctXKE4Qf6qJF8DFk3BBcKzojLjMHH71gnMvKsfuwy6PbE0Aj Gm0KtrTUVXmCWbNV3crlA7iZy0LYuaXNk2vpS33eNqpmmioVZa9Qdh3MJMKrb8zzCMhN VJ5Q== 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=UfkrVNpxTfqN68LmiA3d3tJD0EK6xGIkYqvdb7lkICo=; b=QQTCH1qJhwI+TRemyDWqX2NG5JxfG/f53aOSasZ8zwTy9yXdTc1C2m5y7JmRz4uunl XTD9OAe9Wclu12vHCVFy1+SL12D5PmuwbtVmax3gnyRwXh1oQl2v0kPvtxfIYTY2bYwm RsviXHSepb0rTb2xRaEnhvEUB9IMGxdeYn9MT3ZcTJDsPA625Yhfrh8+mHRxxb3xOZDo SXJfr8HfQmjPBouKCxc2M3XJ8YFqYgJuhp3M8wCV8wsOA2RGNBOCGwfsXSMczacf4Jg9 tVyy6xK7mTKl9adPJlMHS8gmcs11EF7Du4Uk9f0cgoorJrGi6X4gVJpQKhbJCyUcaAvW 9wIA== 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 f25si2916725pge.163.2018.01.26.04.23.17; Fri, 26 Jan 2018 04:23:32 -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 S1751934AbeAZMWc (ORCPT + 99 others); Fri, 26 Jan 2018 07:22:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:49523 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751793AbeAZMWb (ORCPT ); Fri, 26 Jan 2018 07:22:31 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9DF72ABF0; Fri, 26 Jan 2018 12:17:58 +0000 (UTC) Date: Fri, 26 Jan 2018 13:17:57 +0100 From: Petr Mladek To: Dave Young 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: <20180126121757.kec5ecxfxf5fprbi@pathway.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180126073724.GA27220@dhcp-128-65.nay.redhat.com> 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 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 Best Regards, Petr