Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2518889pxb; Sun, 23 Jan 2022 07:14:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTW39/yyqfPO+V8cHDa6ag+DFACOxskRqoHgnbW3qIKQ8jFUTxyfvPxZJM4y/zRNSifGMZ X-Received: by 2002:a17:90a:f005:: with SMTP id bt5mr9260847pjb.169.1642950877313; Sun, 23 Jan 2022 07:14:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642950877; cv=none; d=google.com; s=arc-20160816; b=clw/g1LZDYXlv6jTHdV1595iDhV0x4HQH5ct7ghg9XtFzlZz/0XqcZ0e+sC/k2zaGT ffNl6HCM4lNHEUtB6MABeEXkb7n89kmBHh9GtAJp6YQT4d/cXqxlM6HyXgvMtWPRKBY8 +wvwhqrX8jqQorchMTqjLbabvjfZdzJI93PQnU7sbLseg6J0fysWGr+oJXctCjGSr+5i Jsmks4CP0GyEgkGxgwsfwiuuqKQlIu7O8f6a1frMsEuKL89bUmY+kbdKVORh51uGq0Wp cRZBUqSDqmSFJ0RsBy7rxjTkwJf6pZhSFNrr7OEyU8maUUOqn+2GU20YzbDanFeMGEeX WHSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=M85Dp1PCDT5EATRSGMkaq8YE1CWlkb1P8zz5WRSMb1M=; b=UtPPJOerKc5va0Y0GLfcg8OJT0miVpwOIfcD07SXofqdlCJgNnkS2MrI4EYnry4WLC lmvho2QbTHHmRY14hlKMQ91T/+3blWFGCBXt/ju/lNt0izswKBPyRg3TYGqP6cxUKdbx cCtvRA6I6U6tZrxuBx6G8liB+FYb7dlpiTtSXpEiPv/CSj/RFt0fMhOiUFgKp+qv4n76 /Labv8czlcqGD7lcmtBj6JJI8SzfyYwjfLVT99eAEkffmGKEZjFY3eoC5MuY6YKLxAQR bO7naFuPCaqsxSeWu46cCsUoYmka2T7/0obXcJU8thyWJSoAXpxepEtBz9kuaH5E07tl YAWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=V+tpx26m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d23si9802581plr.301.2022.01.23.07.14.25; Sun, 23 Jan 2022 07:14:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=V+tpx26m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233627AbiAVNuJ (ORCPT + 99 others); Sat, 22 Jan 2022 08:50:09 -0500 Received: from fanzine2.igalia.com ([213.97.179.56]:42842 "EHLO fanzine2.igalia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233294AbiAVNuH (ORCPT ); Sat, 22 Jan 2022 08:50:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=M85Dp1PCDT5EATRSGMkaq8YE1CWlkb1P8zz5WRSMb1M=; b=V+tpx26mZ9hfX8uVUPwzbJl+iZ Lbmf1b3dHlkOFC2YHPA09pXixS4y/tnfaEGlm8F+I2ffqyULD8E/HbBrAuKvi81d7F2kIXFGArYqp YNpd3H2KlprHPPv/hDsa3ikbkT17egjsMbZ3SqtRmVV8NMixvJMGLaP2OPg3R23E14PLpRBEuH+bT xs0AfkM4E2Li4MNacMWWAwQkcyTi1O8CGVceiMW5/no24obwr59TQEbeb4z8DDWJlbjBYlDGc8VlR SNuFLxe2LT6E3zwS5qmwTvKSOUypKIotMMU/LYuoRawPwprj+xXZOO2tjqTTi+dcsOVQU3y9EwbLU UZ63sR1g==; Received: from [179.98.77.138] (helo=[192.168.1.60]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1nBGmD-0002nY-S2; Sat, 22 Jan 2022 14:49:58 +0100 Message-ID: Date: Sat, 22 Jan 2022 10:49:38 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3] panic: Move panic_print before kmsg dumpers Content-Language: en-US To: Baoquan He Cc: Petr Mladek , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, kernel@gpiccoli.net, senozhatsky@chromium.org, rostedt@goodmis.org, john.ogness@linutronix.de, feng.tang@intel.com, kexec@lists.infradead.org, dyoung@redhat.com, keescook@chromium.org, anton@enomsg.org, ccross@android.com, tony.luck@intel.com References: <20220114183046.428796-1-gpiccoli@igalia.com> <20220119071318.GA4977@MiWiFi-R3L-srv> <20220120085115.GB18398@MiWiFi-R3L-srv> <63621138-2a41-26c2-524e-d889068f157a@igalia.com> <20220121023119.GB4579@MiWiFi-R3L-srv> <20220122103121.GB2596@MiWiFi-R3L-srv> From: "Guilherme G. Piccoli" In-Reply-To: <20220122103121.GB2596@MiWiFi-R3L-srv> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/01/2022 07:31, Baoquan He wrote: > [...] > From my old POV, I took pstore as a necessity on handheld devices or > embeded system, e.g on Andriod. In that case, reserving crashkernel > memory to enable kdump to save kernel log, it sounds not so > cost-effective, since memory on those systems is usually not big. > I am also interested in any new use case where people deploy these > and why it's needed, to widen my view. Hi Baoquan, that's great to hear. Indeed, I feel pstore is unfortunately not very used in non-embedded devices - if you see kdump/error-report userspace tooling, like on Red Hat/Fedora, Debian/Ubuntu and so on, they never rely on pstore. And the configuration is not straightforward for the users...I think that's a good thing to change, since pstore is much less resource consuming than kdump. But of course, not a discussion related to this patch specifically, just me thinking out loud heh > [...] > It's my bad. My thought is panic_print and kmsg_dump can be coupled, but > they should decouple with panic_notifier. When panic_print is enabled, > we do not expect to execute panic_notifier? My personal opinion. > > I missed the change at line 8, sorry for the caused misunderstanding. > Now the chance of holding C-programmer-prize of the year comes back > again. > > void panic() > { > 1 if (!_crash_kexec_post_notifiers && !panic_print) { > 2 __crash_kexec(NULL); > 3 smp_send_stop(); > 4 } else { > 5 crash_smp_send_stop(); > 6 } > > if (_crash_kexec_post_notifiers) > 8 atomic_notifier_call_chain(&panic_notifier_list, 0, buf); > 9 panic_print_sys_info(false); > 10 kmsg_dump(KMSG_DUMP_PANIC); > 11 if (_crash_kexec_post_notifiers || panic_print) > 12 __crash_kexec(NULL); > ... > debug_locks_off(); > console_flush_on_panic(CONSOLE_FLUSH_PENDING); > panic_print_sys_info(true); Hmm, yeah, I still don't think I'm a brilliant C programmer heh Again, in the code above, I can't see how we would reach "__crash_kexec(NULL)" after printing the extra info of panic_print, if we don't have panic notifiers enabled. So, indeed the code currently don't really tightly couple "panic_print" with the panic notifiers. We could change that in another patch series, based on what Petr suggested in the filter thread (I know you're following there as well, thanks bu the way!), but for now, they are completely independent. My plan, following Petr suggestions here and if you agree, is to re-submit this patch with some changes, but in the end the code will allow users that have kdump enabled + panic_print -"crash_kexec_post_notifiers" to have "panic_print_sys_info(false)" executing before the "__crash_kexec(NULL)". But also, we can add "crash_kexec_post_notifiers" and it will still work; finally, pstore is gonna be able to collect the logs from "panic_print" as well (the main purpose of this patch). Once that's all resolved, my goal is to jump into the panic notifiers refactor suggested in the other thread. Let me know if you agree with these steps/plans, and I'll work them. Cheers, Guilherme