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 71877C43219 for ; Fri, 13 May 2022 14:46:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1381523AbiEMOqL (ORCPT ); Fri, 13 May 2022 10:46:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1381450AbiEMOp6 (ORCPT ); Fri, 13 May 2022 10:45:58 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBB093C4B7; Fri, 13 May 2022 07:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=A7LCydQD5IYNzaoDGyfG1KKM7tCxGhr7TuWULSo03X0=; t=1652453114; x=1653662714; b=LYs2Kri0cw+/UGCEdaklFX6++OP3d6XjJhLcC02jkMM6M13 enCTtLPVnFDCrQRFLX819G3cOwVdjYiBSa9JccmqbQblnXISEdyq/7i5O4aMDV5xAFeJh8X61XWYA 3hNxcWPO6okKyPbXVAhEt6WHQ/sVkV0gcWR0C3dCeQWocdHTJKZWVZ25I4x63uWgmbhevhAje3sRQ ynAaFSpM6xFAePbWKVwYY4aWUVh0Ju93mi2MceapTMkNIryb6lt7v4/iXwdFQzg89Tz18COaji5Fq iSqUu6mUSMMlAVO2Bcj32MYDMrCOrP4TWkawclAlZw9o6WbW7KIcYMOBD7zR8fsA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1npWX2-00AdYm-Tp; Fri, 13 May 2022 16:44:41 +0200 Message-ID: <1760d499824f9ef053af7a8dac04b48ab7d7fd3d.camel@sipsolutions.net> Subject: Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering From: Johannes Berg To: "Guilherme G. Piccoli" , Petr Mladek , Anton Ivanov , Richard Weinberger 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 Date: Fri, 13 May 2022 16:44:36 +0200 In-Reply-To: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org On Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes 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 F0AAAC433EF for ; Fri, 13 May 2022 15:10:05 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L0Bs81bg8z3cLy for ; Sat, 14 May 2022 01:10:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=sipsolutions.net header.i=@sipsolutions.net header.a=rsa-sha256 header.s=mail header.b=kmw8g9sR; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sipsolutions.net (client-ip=2a01:4f8:191:4433::2; helo=sipsolutions.net; envelope-from=johannes@sipsolutions.net; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=sipsolutions.net header.i=@sipsolutions.net header.a=rsa-sha256 header.s=mail header.b=kmw8g9sR; dkim-atps=neutral X-Greylist: delayed 1456 seconds by postgrey-1.36 at boromir; Sat, 14 May 2022 01:09:24 AEST Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) (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 4L0BrN1ypnz3bqK for ; Sat, 14 May 2022 01:09:24 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=A7LCydQD5IYNzaoDGyfG1KKM7tCxGhr7TuWULSo03X0=; t=1652454564; x=1653664164; b=kmw8g9sRBPM2Km5+Mc+Vnyja0TqQprPnH+PBGuEkkXIVnxx FyBOKV0xCQxRu4lwmUHhP3PMPgwACqxv7vCqkw4D4Zsq6Ifl3sQzOKLUfdPCCSWHPHWQGaU4Piv8c m17N7lgWJNWFjiQ+jQ48SQSJxgYAIx8z0RnMPLysa1MPE7JZCnwl/DvvYakvx6GvtfuGEYKKC46hg WBfJiHsvZ21IszscVVWXXUNhSuMbHQWobX34LA4dYSuu8mlKlVoZh8lomap82Rx+/sKHGnpciUaeW dwGGczORBDdRirGon+Okh9vMd5qz5wtfE3Eb/P2NLd6fk4MmFUuxmL7k9Po9SyxQ==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1npWX2-00AdYm-Tp; Fri, 13 May 2022 16:44:41 +0200 Message-ID: <1760d499824f9ef053af7a8dac04b48ab7d7fd3d.camel@sipsolutions.net> Subject: Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering From: Johannes Berg To: "Guilherme G. Piccoli" , Petr Mladek , Anton Ivanov , Richard Weinberger Date: Fri, 13 May 2022 16:44:36 +0200 In-Reply-To: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned 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 Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Date: Fri, 13 May 2022 16:44:36 +0200 Subject: [PATCH 11/30] um: Improve panic notifiers consistency and ordering In-Reply-To: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Message-ID: <1760d499824f9ef053af7a8dac04b48ab7d7fd3d.camel@sipsolutions.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kexec@lists.infradead.org On Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1760d499824f9ef053af7a8dac04b48ab7d7fd3d.camel@sipsolutions.net> Subject: Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering From: Johannes Berg Date: Fri, 13 May 2022 16:44:36 +0200 In-Reply-To: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> MIME-Version: 1.0 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: "Guilherme G. Piccoli" , Petr Mladek , Anton Ivanov , Richard Weinberger 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 Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes _______________________________________________ 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: Johannes Berg Subject: Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering Date: Fri, 13 May 2022 16:44:36 +0200 Message-ID: <1760d499824f9ef053af7a8dac04b48ab7d7fd3d.camel@sipsolutions.net> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.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:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p7v/mn0e7A/oF+pPOfx9nH4nET67AfE71x8m3SQR2Do=; b=zqvLvGz3Pbi3ij Q3L14XPisqImqW3zVvRYYWfzOuyL9S1kcx5fAcSgcQu6F3B0GO5KP5DB6HIYqCHn7UcSreKFn7Xs5 GpJ0d/9xgVEfU5zBnAYR+1RdJxQHs8WtTEUvjnj1/cm2VeCbId41hOlKAYH03J2ILWir+R8ekckRJ CrnwobC1umYu/iCxr4ztLyWU9NDpPzN377QMUz+/sQdL8AlumeM0F5XPDi+8INHmncOP7+ub9MXVj sXX6prjx4GC6SbwDKGIk/M/NUNMs2fr+nXGiUhshUseLgnKnSFFYqir8XlnZzycERBMpvQjYqWlqd uKtrtN8vP9KFoEtD8Amw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=A7LCydQD5IYNzaoDGyfG1KKM7tCxGhr7TuWULSo03X0=; t=1652453102; x=1653662702; b=l5dx++UGPMWpinqbWuV6X7W79ICDSQhHgZa20/LL2CQAL3L Jjmr/2bZ/Un2EW2MTwaePUpsTsE4jQH5holVDvFD9qWaF5+jLvGgk/re6ULDd/PwGzqJSK9sCk0OI owrJVpRhWMYgdZrC4ERUMw9uTZf0ly1ZH7jv4A1cUZbaCXvtGjXbHUzzXl6Jn9gYseS+S6QiO8p2u bQ2GGVWL4zxmrUAltZ+Jin1oF4Zvi8uK6ku42owyDrFBrsLVkLzZQR9JmRymBaC16DpbzVq+KCK6S UGsMyQCJjUyt/n3Bh6EJyIE40xES6VJcG95W5AchocGSTKFiG815aO7ga57kq3Fw==; In-Reply-To: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.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: "Guilherme G. Piccoli" , Petr Mladek , Anton Ivanov , Richard Weinberger 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, c On Wed, 2022-05-11 at 17:22 -0300, Guilherme G. Piccoli wrote: > On 10/05/2022 11:28, Petr Mladek wrote: > > [...] > > It is not clear to me why user mode linux should not care about > > the other notifiers. It might be because I do not know much > > about the user mode linux. > > > > Is the because they always create core dump or are never running > > in a hypervisor or ...? > > > > AFAIK, the notifiers do many different things. For example, there > > is a notifier that disables RCU watchdog, print some extra > > information. Why none of them make sense here? > > > > Hi Petr, my understanding is that UML is a form of running Linux as a > regular userspace process for testing purposes. Correct. > With that said, as soon > as we exit in the error path, less "pollution" would happen, so users > can use GDB to debug the core dump for example. > > In later patches of this series (when we split the panic notifiers in 3 > lists) these UML notifiers run in the pre-reboot list, so they run after > the informational notifiers for example (in the default level). > But without the list split we cannot order properly, so my gut feeling > is that makes sense to run them rather earlier than later in the panic > process... > > Maybe Anton / Johannes / Richard could give their opinions - appreciate > that, I'm not attached to the priority here, it's more about users' > common usage of UML I can think of... It's hard to say ... In a sense I'm not sure it matters? OTOH something like the ftrace dump notifier (kernel/trace/trace.c) might still be useful to run before the mconsole and coredump ones, even if you could probably use gdb to figure out the information. Personally, I don't have a scenario where I'd care about the trace buffers though, and most of the others I found would seem irrelevant (drivers that aren't even compiled, hung tasks won't really happen since we exit immediately, and similar.) johannes