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 4E74AC433F5 for ; Wed, 11 May 2022 20:24:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347752AbiEKUYW (ORCPT ); Wed, 11 May 2022 16:24:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238984AbiEKUYR (ORCPT ); Wed, 11 May 2022 16:24:17 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0345A72E01; Wed, 11 May 2022 13:24:17 -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=LCKlEcL/+gLbho7zoJo89g9MDYx2GFkg8N7n1nlW+0g=; b=MQpyMZ3nMM+SlSF0Ic+7AggIHS wWCWxLFJNdpcNC/qKw1wNJR3uSo8xMkfiJlq7d2aikSbZG9yuq1pfGOyawWDcFgWnRsla4fbF455Y 3RXCIUoMIO9o6uix81B+J++RZraHoxYIg5AFTEzg2KmNpXSrs7BEjvRicrp5TYhs6s3mYN27kkyAz njPDxaRSeQ75fkZPzqisnL9xIuav4szhmycF8VItK7avDyCoEE8U/Zs7xTZO8x+jizmxi0qGskMhG GsWdK7oyZ7kJDFhpPsgWAmAhF7aiE+T5aNpN2RQ5WYTzC7ql7jtRy3esjCfYNiJNCeB+2D6JHceeB Ayva3vzg==; 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 1noss0-000Aod-US; Wed, 11 May 2022 22:23:41 +0200 Message-ID: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Date: Wed, 11 May 2022 17:22:22 -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 11/30] um: Improve panic notifiers consistency and ordering Content-Language: en-US To: Petr Mladek , Anton Ivanov , Johannes Berg , 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 References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-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 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. 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... 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 E3A8DC433F5 for ; Wed, 11 May 2022 20:24:58 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Kz5xP2R9Tz3cLc for ; Thu, 12 May 2022 06:24:57 +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=MQpyMZ3n; 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=MQpyMZ3n; 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 4Kz5wj31cwz3bWt for ; Thu, 12 May 2022 06:24:21 +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=LCKlEcL/+gLbho7zoJo89g9MDYx2GFkg8N7n1nlW+0g=; b=MQpyMZ3nMM+SlSF0Ic+7AggIHS wWCWxLFJNdpcNC/qKw1wNJR3uSo8xMkfiJlq7d2aikSbZG9yuq1pfGOyawWDcFgWnRsla4fbF455Y 3RXCIUoMIO9o6uix81B+J++RZraHoxYIg5AFTEzg2KmNpXSrs7BEjvRicrp5TYhs6s3mYN27kkyAz njPDxaRSeQ75fkZPzqisnL9xIuav4szhmycF8VItK7avDyCoEE8U/Zs7xTZO8x+jizmxi0qGskMhG GsWdK7oyZ7kJDFhpPsgWAmAhF7aiE+T5aNpN2RQ5WYTzC7ql7jtRy3esjCfYNiJNCeB+2D6JHceeB Ayva3vzg==; 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 1noss0-000Aod-US; Wed, 11 May 2022 22:23:41 +0200 Message-ID: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Date: Wed, 11 May 2022 17:22:22 -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 11/30] um: Improve panic notifiers consistency and ordering Content-Language: en-US To: Petr Mladek , Anton Ivanov , Johannes Berg , Richard Weinberger References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-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 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. 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... Cheers, Guilherme From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guilherme G. Piccoli Date: Wed, 11 May 2022 17:22:22 -0300 Subject: [PATCH 11/30] um: Improve panic notifiers consistency and ordering In-Reply-To: References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-gpiccoli@igalia.com> Message-ID: <4b003501-f5c3-cd66-d222-88d98c93e141@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 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. 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... Cheers, Guilherme From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> Date: Wed, 11 May 2022 17:22:22 -0300 MIME-Version: 1.0 Subject: Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering Content-Language: en-US References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-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 , Anton Ivanov , Johannes Berg , 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 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. 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... 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 11/30] um: Improve panic notifiers consistency and ordering Date: Wed, 11 May 2022 17:22:22 -0300 Message-ID: <4b003501-f5c3-cd66-d222-88d98c93e141@igalia.com> References: <20220427224924.592546-1-gpiccoli@igalia.com> <20220427224924.592546-12-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=LCKlEcL/+gLbho7zoJo89g9MDYx2GFkg8N7n1nlW+0g=; b=MQpyMZ3nMM+SlSF0Ic+7AggIHS wWCWxLFJNdpcNC/qKw1wNJR3uSo8xMkfiJlq7d2aikSbZG9yuq1pfGOyawWDcFgWnRsla4fbF455Y 3RXCIUoMIO9o6uix81B+J++RZraHoxYIg5AFTEzg2KmNpXSrs7BEjvRicrp5TYhs6s3mYN27kkyAz njPDxaRSeQ75fkZPzqisnL9xIuav4szhmycF8VItK7avDyCoEE8U/Zs7xTZO8x+jizmxi0qGskMhG GsWdK7oyZ7kJDFhpPsgWAmAhF7aiE+T5aNpN2RQ5WYTzC7ql7jtRy3esjCfYNiJNCeB+2D6JHceeB Ayva3vz Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Petr Mladek , Anton Ivanov , Johannes Berg , 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 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. 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... Cheers, Guilherme