From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 370C5C433F5 for ; Tue, 17 May 2022 23:29:12 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L2slB66mQz3f6s for ; Wed, 18 May 2022 09:29:10 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.a=rsa-sha256 header.s=20170329 header.b=cRMrVSVT; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=igalia.com (client-ip=178.60.130.6; helo=fanzine2.igalia.com; envelope-from=gpiccoli@igalia.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.a=rsa-sha256 header.s=20170329 header.b=cRMrVSVT; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4L2klD3gK7z2xgJ for ; Wed, 18 May 2022 04:13:42 +1000 (AEST) 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=6MSK1Z4Nv/e1GFKFinCP8P3dIYao0CoLyUe3quXpDhY=; b=cRMrVSVTR+3cn6FVG65SC4Au0y UkLE3SVfqGk36g/jG1E9IomGRvED5Awi+eOSCTntuGE0jPXl5+kfHlbKsvhvVjaCNf8y4mBWXGPlT 8r/o/CMKhbUaIdrKhLkt446cgXa07HTSiorku/w0xJvIn3aE4uqi2qj8QGi7eb4Kmsg0/Wh5BR8Vi YCGb8f9djqv6fWXVwjRpFQtg+9b6W6H4TQisr9ZwQKSIB4SsmfEWL196/jrcNQFL2lm66S4LfYE8s uZ+fz2jSIIuBy2Np//l8BP/gbXHu+JyZVeJsb8IAXoZSlvi3RYMR9sSIMXj8sSzR7kYxeP4KKKokk nGGtp5Zg==; Received: from 200-161-159-120.dsl.telesp.net.br ([200.161.159.120] 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 1nr1gv-008nSU-6m; Tue, 17 May 2022 20:13:05 +0200 Message-ID: <62a63fc2-346f-f375-043a-fa21385279df@igalia.com> Date: Tue, 17 May 2022 15:12:25 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list Content-Language: en-US To: "Luck, Tony" , Petr Mladek , Dinh Nguyen References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-22-gpiccoli@igalia.com> <63a74b56-89ef-8d1f-d487-cdb986aab798@igalia.com> <599b72f6-76a4-8e6d-5432-56fb1ffd7e0b@igalia.com> <06d85642fef24bc482642d669242654b@intel.com> From: "Guilherme G. Piccoli" In-Reply-To: <06d85642fef24bc482642d669242654b@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 18 May 2022 09:23:23 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Mackerras , Pavel Machek , Alexander Gordeev , "K. Y. Srinivasan" , Wei Liu , "stern@rowland.harvard.edu" , "xen-devel@lists.xenproject.org" , Matt Turner , Christian Borntraeger , "linux-pm@vger.kernel.org" , "linux-um@lists.infradead.org" , "luto@kernel.org" , "tglx@linutronix.de" , Alex Elder , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , "senozhatsky@chromium.org" , "d.hatayama@jp.fujitsu.com" , Bjorn Andersson , Sven Schnelle , "akpm@linux-foundation.org" , "linux-hyperv@vger.kernel.org" , "dave.hansen@linux.intel.com" , "James E.J. Bottomley" , Max Filippov , "linux-s390@vger.kernel.org" , Stefano Stabellini , Stephen Hemminger , Corey Minyard , Helge Deller , "vgoyal@redhat.com" , "mhiramat@kernel.org" , Vasily Gorbik , "linux-xtensa@linux-xtensa.org" , "john.ogness@linutronix.de" , "hidehiro.kawai.ez@hitachi.com" , Boris Ostrovsky , Chris Zankel , Mathieu Poirier , James Morse , "kernel-dev@igalia.com" , "fabiomirmar@gmail.com" , "halves@canonical.com" , "alejandro.j.jimenez@oracle.com" , "Tang, Feng" , "will@kernel.org" , "bhe@redhat.com" , "corbet@lwn.net" , Dexuan Cui , "bcm-kernel-feedback-list@broadcom.com" , Robert Richter , "keescook@chromium.org" , "arnd@arndb.de" , Haiyang Zhang , "rostedt@goodmis.org" , "rcu@vger.kernel.org" , "bp@alien8.de" , "openipmi-developer@lists.sourceforge.net" , Mauro Carvalho Chehab , "linux-parisc@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "peterz@infradead.org" , "linux-remoteproc@vger.kernel.org" , "mikelley@microsoft.com" , "H. Peter Anvin" , "sparclinux@vger.kernel.org" , "linux-leds@vger.kernel.org" , Anton Ivanov , Richard Weinberger , "x86@kernel.org" , "mingo@redhat.com" , "dyoung@redhat.com" , "paulmck@kernel.org" , Heiko Carstens , "linux-tegra@vger.kernel.org" , "andriy.shevchenko@linux.intel.com" , Johannes Berg , "linux-edac@vger.kernel.org" , "jgross@suse.com" , "netdev@vger.kernel.org" , "kernel@gpiccoli.net" , "kexec@lists.infradead.org" , "linux-mips@vger.kernel.org" , Ivan Kokshaysky , "vkuznets@redhat.com" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 17/05/2022 14:02, Luck, Tony wrote: >> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else >> we run the code as-is? Does that make sense to you? > > The "skip" option sounds like it needs some special flag associated with > an entry on the notifier chain. But there are other notifier chains ... so that > sounds messy to me. > > Just all the notifiers in priority order. If any want to take different actions > based on kdump status, change the code. That seems more flexible than > an "all or nothing" approach by skipping. > > -Tony I guess I've expressed myself in a poor way - sorry! What I'm planning to do in the altera_edac notifier is: if (kdump_is_set) return; /* regular code */ In other words: if the kdump is set, this notifier will be effectively a nop (although it's gonna be called). Lemme know your thoughts Tony, if that makes sense. Thanks, Guilherme