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 F2E43C433F5 for ; Mon, 7 Mar 2022 14:05:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242987AbiCGOFy (ORCPT ); Mon, 7 Mar 2022 09:05:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233239AbiCGOFw (ORCPT ); Mon, 7 Mar 2022 09:05:52 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D5DCD5AECE for ; Mon, 7 Mar 2022 06:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646661897; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+/lGec4dDaa2PRCmRBpnfAUw2RsLSGmneKuOWF+Jy7s=; b=Wq4UVYcYFUmouqf3RNaoTlP4H5MnlXm/EU+99YyWODt1gWNGns7OG16ph3HHAIHqz6Iagh Lw4UlMXaal1A6JLdDiNG6sWxyzBkM77f+Z3aYow5XdvqZRRuNTtO1vZFm5FD4ptRK9Jht2 eDaL5WgH4CCbR95s68jaS1aoxXRfMsA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-590-T9rlbQuhOnSjEboWkQd7lQ-1; Mon, 07 Mar 2022 09:04:53 -0500 X-MC-Unique: T9rlbQuhOnSjEboWkQd7lQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7E6A3801DDB; Mon, 7 Mar 2022 14:04:51 +0000 (UTC) Received: from localhost (ovpn-13-211.pek2.redhat.com [10.72.13.211]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2FF417A542; Mon, 7 Mar 2022 14:04:49 +0000 (UTC) Date: Mon, 7 Mar 2022 22:04:47 +0800 From: "bhe@redhat.com" To: "Guilherme G. Piccoli" Cc: Petr Mladek , "d.hatayama@fujitsu.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "dyoung@redhat.com" , "linux-doc@vger.kernel.org" , "vgoyal@redhat.com" , "stern@rowland.harvard.edu" , "akpm@linux-foundation.org" , "andriy.shevchenko@linux.intel.com" , "corbet@lwn.net" , "halves@canonical.com" , "kernel@gpiccoli.net" Subject: Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter Message-ID: References: <20220108153451.195121-1-gpiccoli@igalia.com> <73011b6f-084b-43f5-cc01-1818a8a57e56@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/22 at 10:11am, Guilherme G. Piccoli wrote: > On 07/03/2022 00:42, bhe@redhat.com wrote: > > [...] > >> Let me know your thoughts Petr / Baoquan - it would add slightly more > >> code / complexity, but in my opinion the payback is very good. > >> Cheers, > > > > The ideal situation is each panic notifier has an order or index to > > indicate its priority. Wondering how to make it. What I think of is > > copying initcall. We have several priorities, at the same priority, > > execution sequence is not important. Not sure if I get your point. > > > > ~~~~~~~ > > #define core_initcall(fn) __define_initcall(fn, 1) > > #define core_initcall_sync(fn) __define_initcall(fn, 1s) > > ...... > > #define late_initcall(fn) __define_initcall(fn, 7) > > #define late_initcall_sync(fn) __define_initcall(fn, 7s) > > > > Hi Baoquan, thanks for you consideration! In fact, the notifiers > infrastructure already have a mechanism of ordering, my idea is to make > use of that. It's not that different from the initcall system... Ah, sorry, I even didn't notice that. That's awesome if we can make use of that. While I still have concerns: 1) about those we have decided to take out from panic notifier list and put before kdump, e.g the Hypver-V notifier, how will we do with it? Are we going to handle them as we have discussed? 2) Combing and settling priority for all existing panic notifier looks great, even though it will take some effort. How about the later newly added one? How can we guarantee that those new notifiers are getting appropriate priority to mark their order? Sometime we even don't know a new panic notifier is added since code change may be made in any component or driver. > > For instance, the code in the notifier register function checks for the > priority field in the notifier block: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/notifier.c#n31 > . > > For example, the Xen panic notifier is one of the few blocks that make > use of that, currently: > > static struct notifier_block xen_panic_block = { > .notifier_call = xen_panic_event, > .priority = INT_MIN > }; > > (see > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/xen/enlighten.c#n286) > > In this case, xen_panic_event() will be the latest one to run. My idea > is to make use of that in *all* panic notifiers, having a table/list on > panic_notifier.h (defines or enum, I'll think about that when writing > this part) so all notifiers are documented and the ordering is clear and > enforced. > > Makes sense to you? > Cheers, > > > Guilherme >