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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DBBBC433FE for ; Tue, 17 May 2022 18:14:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352125AbiEQSOf (ORCPT ); Tue, 17 May 2022 14:14:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351992AbiEQSN4 (ORCPT ); Tue, 17 May 2022 14:13:56 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05D2E50E0D; Tue, 17 May 2022 11:13:32 -0700 (PDT) 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 Cc: "akpm@linux-foundation.org" , "bhe@redhat.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "bcm-kernel-feedback-list@broadcom.com" , "linuxppc-dev@lists.ozlabs.org" , "linux-alpha@vger.kernel.org" , "linux-edac@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-leds@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "linux-um@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , "netdev@vger.kernel.org" , "openipmi-developer@lists.sourceforge.net" , "rcu@vger.kernel.org" , "sparclinux@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "x86@kernel.org" , "kernel-dev@igalia.com" , "kernel@gpiccoli.net" , "halves@canonical.com" , "fabiomirmar@gmail.com" , "alejandro.j.jimenez@oracle.com" , "andriy.shevchenko@linux.intel.com" , "arnd@arndb.de" , "bp@alien8.de" , "corbet@lwn.net" , "d.hatayama@jp.fujitsu.com" , "dave.hansen@linux.intel.com" , "dyoung@redhat.com" , "Tang, Feng" , "gregkh@linuxfoundation.org" , "mikelley@microsoft.com" , "hidehiro.kawai.ez@hitachi.com" , "jgross@suse.com" , "john.ogness@linutronix.de" , "keescook@chromium.org" , "luto@kernel.org" , "mhiramat@kernel.org" , "mingo@redhat.com" , "paulmck@kernel.org" , "peterz@infradead.org" , "rostedt@goodmis.org" , "senozhatsky@chromium.org" , "stern@rowland.harvard.edu" , "tglx@linutronix.de" , "vgoyal@redhat.com" , "vkuznets@redhat.com" , "will@kernel.org" , Alex Elder , Alexander Gordeev , Anton Ivanov , Benjamin Herrenschmidt , Bjorn Andersson , Boris Ostrovsky , Chris Zankel , Christian Borntraeger , Corey Minyard , Dexuan Cui , "H. Peter Anvin" , Haiyang Zhang , Heiko Carstens , Helge Deller , Ivan Kokshaysky , "James E.J. Bottomley" , James Morse , Johannes Berg , "K. Y. Srinivasan" , Mathieu Poirier , Matt Turner , Mauro Carvalho Chehab , Max Filippov , Michael Ellerman , Paul Mackerras , Pavel Machek , Richard Weinberger , Robert Richter , Stefano Stabellini , Stephen Hemminger , Sven Schnelle , Vasily Gorbik , Wei Liu 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 Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guilherme G. Piccoli Date: Tue, 17 May 2022 15:12:25 -0300 Subject: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list In-Reply-To: <06d85642fef24bc482642d669242654b@intel.com> 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> Message-ID: <62a63fc2-346f-f375-043a-fa21385279df@igalia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <62a63fc2-346f-f375-043a-fa21385279df@igalia.com> Date: Tue, 17 May 2022 15:12:25 -0300 MIME-Version: 1.0 Subject: Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list Content-Language: en-US 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> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: "Luck, Tony" , Petr Mladek , Dinh Nguyen Cc: "akpm@linux-foundation.org" , "bhe@redhat.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "bcm-kernel-feedback-list@broadcom.com" , "linuxppc-dev@lists.ozlabs.org" , "linux-alpha@vger.kernel.org" , "linux-edac@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-leds@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "linux-um@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , "netdev@vger.kernel.org" , "openipmi-developer@lists.sourceforge.net" , "rcu@vger.kernel.org" , "sparclinux@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "x86@kernel.org" , "kernel-dev@igalia.com" , "kernel@gpiccoli.net" , "halves@canonical.com" , "fabiomirmar@gmail.com" , "alejandro.j.jimenez@oracle.com" , "andriy.shevchenko@linux.intel.com" , "arnd@arndb.de" , "bp@alien8.de" , "corbet@lwn.net" , "d.hatayama@jp.fujitsu.com" , "dave.hansen@linux.intel.com" , "dyoung@redhat.com" , "Tang, Feng" , "gregkh@linuxfoundation.org" , "mikelley@microsoft.com" , "hidehiro.kawai.ez@hitachi.com" , "jgross@suse.com" , "john.ogness@linutronix.de" , "keescook@chromium.org" , "luto@kernel.org" , "mhiramat@kernel.org" , "mingo@redhat.com" , "paulmck@kernel.org" , "peterz@infradead.org" , "rostedt@goodmis.org" , "senozhatsky@chromium.org" , "stern@rowland.harvard.edu" , "tglx@linutronix.de" , "vgoyal@redhat.com" , "vkuznets@redhat.com" , "will@kernel.org" , Alex Elder , Alexander Gordeev , Anton Ivanov , Benjamin Herrenschmidt , Bjorn Andersson , Boris Ostrovsky , Chris Zankel , Christian Borntraeger , Corey Minyard , Dexuan Cui , "H. Peter Anvin" , Haiyang Zhang , Heiko Carstens , Helge Deller , Ivan Kokshaysky , "James E.J. Bottomley" , James Morse , Johannes Berg , "K. Y. Srinivasan" , Mathieu Poirier , Matt Turner , Mauro Carvalho Chehab , Max Filippov , Michael Ellerman , Paul Mackerras , Pavel Machek , Richard Weinberger , Robert Richter , Stefano Stabellini , Stephen Hemminger , Sven Schnelle , Vasily Gorbik , Wei Liu 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Guilherme G. Piccoli" Subject: Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list Date: Tue, 17 May 2022 15:12:25 -0300 Message-ID: <62a63fc2-346f-f375-043a-fa21385279df@igalia.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RkcNvrzFzF9FtcobFoiblw/OIAiv7NXlH/of41nBjZg=; b=1nbZmVL9gt1iBS rydNgNWiMBGNdNhtfb6iCNlHKXH/BDshOCdUZKj/xLhEk38xXmGqDJgCWoPN+f9UB6H8x8+a1h0sj M787EgY/X7rd9mxONDoscOMQ9bQQIfaWRD1wuHAsUmwTRvzrb1NYm4IQpgPs5yRGE1Rz32UCcQYb9 Km+AtXOEMODIcsPWKTBvzKmopO1fdZAqisUCYNybIxlgM8x1clkf9kLLBFlBoYQu45J3bIjrrWYHV RVxH6xPGybsNHA4DslJFV1g9LWykuYbn10BqkPRUZ9DFDt3bU6dAAwMMs0UtEcJlZOA+3iubyrOzs mLBGuq527unGbTaMmUjw==; 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==; Content-Language: en-US In-Reply-To: <06d85642fef24bc482642d669242654b@intel.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+glud-user-mode-linux-devel=m.gmane-mx.org@lists.infradead.org To: "Luck, Tony" , Petr Mladek , Dinh Nguyen Cc: "akpm@linux-foundation.org" , "bhe@redhat.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "bcm-kernel-feedback-list@broadcom.com" , "linuxppc-dev@lists.ozlabs.org" , "linux-alpha@vger.kernel.org" , "linux-edac@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-leds@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "linux-s390@vger.kernel.org" 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