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 2D1ABC4332F for ; Tue, 10 May 2022 16:18:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347228AbiEJQV5 (ORCPT ); Tue, 10 May 2022 12:21:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347193AbiEJQVr (ORCPT ); Tue, 10 May 2022 12:21:47 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C21D428ED28; Tue, 10 May 2022 09:17:47 -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=DG+kC/U+ySej5D6tfV4OCa8YH0d8ESpuNC4bFJt4RU8=; b=C2KkFYKUIxmXZpa9w2+Tc0j2Ea RFFr76ch465vsOUiMZW1uqZNDnhRYy0QqpFeaougTFG9GOX2EvcKO8NnFtvJdvaTDSvmTGm5I6bLE gx/SYLZAEuVfjx7NJeu1tB8cieKdzixVjql/phg2ZRqRsu9xZgqdP1nbzw6Nv7UUXN3Dua0weQYl6 +N3ACyNpHY020LPMtgokauBK3/rzBv0qIzP0VJEueNDPsJdk0Noe60ugWXyfyRTapgsSXBPVXAg4/ oobDhrEfQYteiYAwrodL1TGkVGLJREzPqDYfYYN3sh0JBT6vnlq6trf1vxZCJI19NPJiA+YiSFKJe qkMs6K7A==; Received: from [177.183.162.244] (helo=[192.168.0.5]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1noSY8-0008UD-Jz; Tue, 10 May 2022 18:17:24 +0200 Message-ID: <244a412c-4589-28d1-bb77-d3648d4f0b12@igalia.com> Date: Tue, 10 May 2022 13:16:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks Content-Language: en-US To: Petr Mladek 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, feng.tang@intel.com, 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 References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-15-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org On 10/05/2022 12:16, Petr Mladek wrote: > [...] > Hmm, this looks like a hack. PANIC_UNUSED will never be used. > All notifiers will be always called with PANIC_NOTIFIER. > > The @val parameter is normally used when the same notifier_list > is used in different situations. > > But you are going to use it when the same notifier is used > in more lists. This is normally distinguished by the @nh > (atomic_notifier_head) parameter. > > IMHO, it is a bad idea. First, it would confuse people because > it does not follow the original design of the parameters. > Second, the related code must be touched anyway when > the notifier is moved into another list so it does not > help much. > > Or do I miss anything, please? > > Best Regards, > Petr Hi Petr, thanks for the review. I'm not strong attached to this patch, so we could drop it and refactor the code of next patches to use the @nh as identification - but personally, I feel this parameter could be used to identify the list that called such function, in other words, what is the event that triggered the callback. Some notifiers are even declared with this parameter called "ev", like the event that triggers the notifier. You mentioned 2 cases: (a) Same notifier_list used in different situations; (b) Same *notifier callback* used in different lists; Mine is case (b), right? Can you show me an example of case (a)? You can see in the following patches (or grep the kernel) that people are using this identification parameter to determine which kind of OOPS trigger the callback to condition the execution of the function to specific cases. IIUIC, this is more or less what I'm doing, but extending the idea for panic notifiers. Again, as a personal preference, it makes sense to me using id's VS comparing pointers to differentiate events/callers. Cheers, 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 EA01CC433EF for ; Tue, 10 May 2022 16:18:39 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KyNWd70jkz3cJt for ; Wed, 11 May 2022 02:18:37 +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=C2KkFYKU; 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=C2KkFYKU; 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 4KyNVr631Qz2xrs for ; Wed, 11 May 2022 02:17:54 +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=DG+kC/U+ySej5D6tfV4OCa8YH0d8ESpuNC4bFJt4RU8=; b=C2KkFYKUIxmXZpa9w2+Tc0j2Ea RFFr76ch465vsOUiMZW1uqZNDnhRYy0QqpFeaougTFG9GOX2EvcKO8NnFtvJdvaTDSvmTGm5I6bLE gx/SYLZAEuVfjx7NJeu1tB8cieKdzixVjql/phg2ZRqRsu9xZgqdP1nbzw6Nv7UUXN3Dua0weQYl6 +N3ACyNpHY020LPMtgokauBK3/rzBv0qIzP0VJEueNDPsJdk0Noe60ugWXyfyRTapgsSXBPVXAg4/ oobDhrEfQYteiYAwrodL1TGkVGLJREzPqDYfYYN3sh0JBT6vnlq6trf1vxZCJI19NPJiA+YiSFKJe qkMs6K7A==; Received: from [177.183.162.244] (helo=[192.168.0.5]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1noSY8-0008UD-Jz; Tue, 10 May 2022 18:17:24 +0200 Message-ID: <244a412c-4589-28d1-bb77-d3648d4f0b12@igalia.com> Date: Tue, 10 May 2022 13:16:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks Content-Language: en-US To: Petr Mladek References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-15-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: linux-hyperv@vger.kernel.org, halves@canonical.com, gregkh@linuxfoundation.org, peterz@infradead.org, alejandro.j.jimenez@oracle.com, linux-remoteproc@vger.kernel.org, feng.tang@intel.com, linux-mips@vger.kernel.org, hidehiro.kawai.ez@hitachi.com, sparclinux@vger.kernel.org, will@kernel.org, tglx@linutronix.de, linux-leds@vger.kernel.org, linux-s390@vger.kernel.org, mikelley@microsoft.com, john.ogness@linutronix.de, bhe@redhat.com, corbet@lwn.net, paulmck@kernel.org, fabiomirmar@gmail.com, x86@kernel.org, mingo@redhat.com, bcm-kernel-feedback-list@broadcom.com, xen-devel@lists.xenproject.org, dyoung@redhat.com, vgoyal@redhat.com, linux-xtensa@linux-xtensa.org, dave.hansen@linux.intel.com, keescook@chromium.org, arnd@arndb.de, linux-pm@vger.kernel.org, linux-um@lists.infradead.org, rostedt@goodmis.org, rcu@vger.kernel.org, bp@alien8.de, luto@kernel.org, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, andriy.shevchenko@linux.intel.com, vkuznets@redhat.com, linux-edac@vger.kernel.org, jgross@suse.com, linux-parisc@vger.kernel.org, netdev@vger.kernel.org, kernel@gpiccoli.net, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, stern@rowland.harvard.edu, senozhatsky@chromium.org, d.hatayama@jp.fujitsu.com, mhiramat@kernel.org, kernel-dev@igalia.com, linux-alpha@vger.kernel.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 10/05/2022 12:16, Petr Mladek wrote: > [...] > Hmm, this looks like a hack. PANIC_UNUSED will never be used. > All notifiers will be always called with PANIC_NOTIFIER. > > The @val parameter is normally used when the same notifier_list > is used in different situations. > > But you are going to use it when the same notifier is used > in more lists. This is normally distinguished by the @nh > (atomic_notifier_head) parameter. > > IMHO, it is a bad idea. First, it would confuse people because > it does not follow the original design of the parameters. > Second, the related code must be touched anyway when > the notifier is moved into another list so it does not > help much. > > Or do I miss anything, please? > > Best Regards, > Petr Hi Petr, thanks for the review. I'm not strong attached to this patch, so we could drop it and refactor the code of next patches to use the @nh as identification - but personally, I feel this parameter could be used to identify the list that called such function, in other words, what is the event that triggered the callback. Some notifiers are even declared with this parameter called "ev", like the event that triggers the notifier. You mentioned 2 cases: (a) Same notifier_list used in different situations; (b) Same *notifier callback* used in different lists; Mine is case (b), right? Can you show me an example of case (a)? You can see in the following patches (or grep the kernel) that people are using this identification parameter to determine which kind of OOPS trigger the callback to condition the execution of the function to specific cases. IIUIC, this is more or less what I'm doing, but extending the idea for panic notifiers. Again, as a personal preference, it makes sense to me using id's VS comparing pointers to differentiate events/callers. Cheers, Guilherme From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guilherme G. Piccoli Date: Tue, 10 May 2022 13:16:54 -0300 Subject: [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks In-Reply-To: References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-15-gpiccoli@igalia.com> Message-ID: <244a412c-4589-28d1-bb77-d3648d4f0b12@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 10/05/2022 12:16, Petr Mladek wrote: > [...] > Hmm, this looks like a hack. PANIC_UNUSED will never be used. > All notifiers will be always called with PANIC_NOTIFIER. > > The @val parameter is normally used when the same notifier_list > is used in different situations. > > But you are going to use it when the same notifier is used > in more lists. This is normally distinguished by the @nh > (atomic_notifier_head) parameter. > > IMHO, it is a bad idea. First, it would confuse people because > it does not follow the original design of the parameters. > Second, the related code must be touched anyway when > the notifier is moved into another list so it does not > help much. > > Or do I miss anything, please? > > Best Regards, > Petr Hi Petr, thanks for the review. I'm not strong attached to this patch, so we could drop it and refactor the code of next patches to use the @nh as identification - but personally, I feel this parameter could be used to identify the list that called such function, in other words, what is the event that triggered the callback. Some notifiers are even declared with this parameter called "ev", like the event that triggers the notifier. You mentioned 2 cases: (a) Same notifier_list used in different situations; (b) Same *notifier callback* used in different lists; Mine is case (b), right? Can you show me an example of case (a)? You can see in the following patches (or grep the kernel) that people are using this identification parameter to determine which kind of OOPS trigger the callback to condition the execution of the function to specific cases. IIUIC, this is more or less what I'm doing, but extending the idea for panic notifiers. Again, as a personal preference, it makes sense to me using id's VS comparing pointers to differentiate events/callers. Cheers, Guilherme From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <244a412c-4589-28d1-bb77-d3648d4f0b12@igalia.com> Date: Tue, 10 May 2022 13:16:54 -0300 MIME-Version: 1.0 Subject: Re: [PATCH 14/30] panic: Properly identify the panic event to the notifiers' callbacks Content-Language: en-US References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-15-gpiccoli@igalia.com> From: "Guilherme G. Piccoli" In-Reply-To: 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: Petr Mladek 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, feng.tang@intel.com, 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 On 10/05/2022 12:16, Petr Mladek wrote: > [...] > Hmm, this looks like a hack. PANIC_UNUSED will never be used. > All notifiers will be always called with PANIC_NOTIFIER. > > The @val parameter is normally used when the same notifier_list > is used in different situations. > > But you are going to use it when the same notifier is used > in more lists. This is normally distinguished by the @nh > (atomic_notifier_head) parameter. > > IMHO, it is a bad idea. First, it would confuse people because > it does not follow the original design of the parameters. > Second, the related code must be touched anyway when > the notifier is moved into another list so it does not > help much. > > Or do I miss anything, please? > > Best Regards, > Petr Hi Petr, thanks for the review. I'm not strong attached to this patch, so we could drop it and refactor the code of next patches to use the @nh as identification - but personally, I feel this parameter could be used to identify the list that called such function, in other words, what is the event that triggered the callback. Some notifiers are even declared with this parameter called "ev", like the event that triggers the notifier. You mentioned 2 cases: (a) Same notifier_list used in different situations; (b) Same *notifier callback* used in different lists; Mine is case (b), right? Can you show me an example of case (a)? You can see in the following patches (or grep the kernel) that people are using this identification parameter to determine which kind of OOPS trigger the callback to condition the execution of the function to specific cases. IIUIC, this is more or less what I'm doing, but extending the idea for panic notifiers. Again, as a personal preference, it makes sense to me using id's VS comparing pointers to differentiate events/callers. Cheers, 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 14/30] panic: Properly identify the panic event to the notifiers' callbacks Date: Tue, 10 May 2022 13:16:54 -0300 Message-ID: <244a412c-4589-28d1-bb77-d3648d4f0b12@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-15-gpiccoli@igalia.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: 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=DG+kC/U+ySej5D6tfV4OCa8YH0d8ESpuNC4bFJt4RU8=; b=C2KkFYKUIxmXZpa9w2+Tc0j2Ea RFFr76ch465vsOUiMZW1uqZNDnhRYy0QqpFeaougTFG9GOX2EvcKO8NnFtvJdvaTDSvmTGm5I6bLE gx/SYLZAEuVfjx7NJeu1tB8cieKdzixVjql/phg2ZRqRsu9xZgqdP1nbzw6Nv7UUXN3Dua0weQYl6 +N3ACyNpHY020LPMtgokauBK3/rzBv0qIzP0VJEueNDPsJdk0Noe60ugWXyfyRTapgsSXBPVXAg4/ oobDhrEfQYteiYAwrodL1TGkVGLJREzPqDYfYYN3sh0JBT6vnlq6trf1vxZCJI19NPJiA+YiSFKJe qkMs6K7 Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Petr Mladek 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 On 10/05/2022 12:16, Petr Mladek wrote: > [...] > Hmm, this looks like a hack. PANIC_UNUSED will never be used. > All notifiers will be always called with PANIC_NOTIFIER. > > The @val parameter is normally used when the same notifier_list > is used in different situations. > > But you are going to use it when the same notifier is used > in more lists. This is normally distinguished by the @nh > (atomic_notifier_head) parameter. > > IMHO, it is a bad idea. First, it would confuse people because > it does not follow the original design of the parameters. > Second, the related code must be touched anyway when > the notifier is moved into another list so it does not > help much. > > Or do I miss anything, please? > > Best Regards, > Petr Hi Petr, thanks for the review. I'm not strong attached to this patch, so we could drop it and refactor the code of next patches to use the @nh as identification - but personally, I feel this parameter could be used to identify the list that called such function, in other words, what is the event that triggered the callback. Some notifiers are even declared with this parameter called "ev", like the event that triggers the notifier. You mentioned 2 cases: (a) Same notifier_list used in different situations; (b) Same *notifier callback* used in different lists; Mine is case (b), right? Can you show me an example of case (a)? You can see in the following patches (or grep the kernel) that people are using this identification parameter to determine which kind of OOPS trigger the callback to condition the execution of the function to specific cases. IIUIC, this is more or less what I'm doing, but extending the idea for panic notifiers. Again, as a personal preference, it makes sense to me using id's VS comparing pointers to differentiate events/callers. Cheers, Guilherme