Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 26 Apr 2022 16:43:45 +0000
From:   Huang Shijie <shijie@os.amperecomputing.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     will@kernel.org, catalin.marinas@arm.com,
        patches@amperecomputing.com, zwang@amperecomputing.com,
        darren@os.amperecomputing.com, pasha.tatashin@soleen.com,
        senozhatsky@chromium.org, rostedt@goodmis.org,
        john.ogness@linutronix.de, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, Adam Li <adam.li@amperecomputing.com>
Subject: Re: [PATCH v2] arm64: kexec: flush log to console in NMI context
Message-ID: <Ymgg6p5TYFOHPbw5@hsj>
References: <20220424151952.183208-1-shijie@os.amperecomputing.com>
 <Ymeq9uD5Sz9iwW8H@alley>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Ymeq9uD5Sz9iwW8H@alley>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?R53k9/veMz852EZtRmIX7LKSZtqtrtIoUS2ithkF04bN5hEmVvYKiQBCWiiq?=
 =?us-ascii?Q?GsHCPmfuTofk3Tb2PVG3gtSs3pONCd6yWBdmiJ1M7EpR8C8d+n/kUKxCT1u4?=
 =?us-ascii?Q?RTh8QWqD6x9RIZsnGMkbDK6ajzHGN68WEqvXyzlzqK4SMpZ4fyWWMU/0+scf?=
 =?us-ascii?Q?XMeolX7A463ZQ+eG1ZMjtr4eeg/BozuRUTwOznpJb2VKp/ZyWTaCZuHN7fZO?=
 =?us-ascii?Q?cAhH7L0HTmUp64+ZOmzda/x7mFKJBOIfxXxRUS6yUL+gNS10Yk9Xia0iaNMJ?=
 =?us-ascii?Q?WoDIhC/ipCm1BTb2BFVN3Ufg8+LlnX+pVSywK7OOhGhXQyxmQ5eKErRdloLh?=
 =?us-ascii?Q?rpkkP5yBeXfYQb297ycNRo95KPvlrRrWsF+cSDbJwxaNwsjY+iqPqmQIixKg?=
 =?us-ascii?Q?XHI3UFCUcJj1ayqyZYA6BrwIuCvEZ2UfyQe5HVlVkmucxi44uEXp6x065QBz?=
 =?us-ascii?Q?0wQ1mphk783KBpQjtyfK0m6R72t+e7QWdFtbzC9mRWxgqYwou+i93Gb399O6?=
 =?us-ascii?Q?Muupa53R79+k3cml9Vxe07Zr5GB3l0vLhy1F6pFFX+42cyowpBDkxCu/Zmzv?=
 =?us-ascii?Q?s5Yfr0qTjgr0DuOxfCryJMUMjRRdfsJjHdETh28f0qHR/qIuNLzTqCaXgHNd?=
 =?us-ascii?Q?tRieyER14oe4Ak8aluFiMfZmKzzup/dfSbEVXaUGyTn0Voacb00m10byxtwj?=
 =?us-ascii?Q?QenvcK+W2n6QnPLSuGS4RyQwqZ9V8DtBirZK+kkMUtXQJ67KLJA8oPTAyGMN?=
 =?us-ascii?Q?lAG46bq7OFervKA3PCL2prFl9BF2SGmB4huRUzJbUmSxPalvjFzfTceVwFds?=
 =?us-ascii?Q?jVgm+m1Vs7bt00L8Vi9KMtfsyzTMMTE8NILzmKSKcpvk0LBKR8PxcJPOAijM?=
 =?us-ascii?Q?uu6fGhptrLfDPWMquXSHnDODWktOf7YcsX8yWbGR2uIeTZnEDX6DtIC8gdiq?=
 =?us-ascii?Q?1PyJcz+n6TmJv+fNb+mGW9/sfqPujL5aW/crAvAqhRCynjTwKNPxx/nAMuy4?=
 =?us-ascii?Q?eWaEt+vPNKCI6VQY2pXq/x4IWoBLFaPPAn0gUbuGXobJhR4Qb8m9fgaNJcvO?=
 =?us-ascii?Q?VMQi+XyEEkWsBtoTpWlrsuif2OioFH6s2fPQffI6Ve1vvrOAQN++AP3ScrbL?=
 =?us-ascii?Q?AiQZSQHCulxP6AGAWoEuuZBvfKg9255HYfZkGP038RlziUksI+HCxCwnGjvi?=
 =?us-ascii?Q?pkJvY6CpVzFJJm/juDA6EGknNIqpKx9M7W60xaNGJmUcmwoZs/wGnYm3Tw4X?=
 =?us-ascii?Q?ghGZy7YZ+Lpv0rS7cF3wgBwHU2zWmbQ9cZseHx59JIGKWeyqRkts8x9J3UEY?=
 =?us-ascii?Q?F4TDhbtMZek4zQOHTaNucUdqUdgXf5CPiHC3OqOgaZoTdbWGsWHcFQmh6xKu?=
 =?us-ascii?Q?AfdaWqeTrSAjKK2LyXflD5jNQzi3BbzUIitTKTQjqTwiKoMnukjCOSPVxfAW?=
 =?us-ascii?Q?hhkksrAxQGfoFc+rRTtbd4D3jrVT4eyyMSJgGWxWKblxf85HXnb+d4/MQfLk?=
 =?us-ascii?Q?scwWctnR3g9Ann57yAe92y1HwlbKBXL+eEKFkUCohNFywwKdTXJZlPv8QaJ6?=
 =?us-ascii?Q?dI9ihYRUlPOwgUGwEwqRWxQyUeRLRqX+utNoKzGM+9P1kqgRsUpSvBPdqVG6?=
 =?us-ascii?Q?waC0/Uno9aDDJ9BE9eLviMmPJTbUOAkzocs/z/AjTQA4Q9UM7P2OP+Bh9ZyT?=
 =?us-ascii?Q?XLLqazAAlb8dvos7JsAuJg2J0Pw7vgWpVPCW2kNpNbN/l4ohnlcpJAFWLogn?=
 =?us-ascii?Q?znuZCfRwIshPRAtq9FfCM/Qe3ud9qBrFHMd3NVNcyP/aigkq7EP/?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a18b5644-c35d-4c52-ac86-08da2761562d
X-MS-Exchange-CrossTenant-AuthSource: DM8PR01MB6824.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2022 08:47:04.1240
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tHlrgEnz74ye2Yq/aTdjM1g5+5IJavXylqFPoQwmO+M9I0HvbVnOLNc635KeREwQSrQ7oF+0hLqz1PEBSfBW3ObsAbzMsf1UBETmGx0IkWRjBey2lmcDRR7EMRtoUwe3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR01MB7505
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=no
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Petr,
On Tue, Apr 26, 2022 at 10:19:02AM +0200, Petr Mladek wrote:
> On Sun 2022-04-24 15:19:52, Huang Shijie wrote:
> > If kdump is configured, nmi_panic() may run to machine_kexec().
> > 
> > In NMI context, the defer_console_output() defers the console
> > output by using wake_up_klogd to flush the printk ringbuffer
> > to console.
> > 
> > But in the machine_kexec, the system will reset, and there is
> > no chance for the wake_up_klogd to do its job. So we can _not_
> > see any log on the console since the nmi_panic
> > (nmi_panic() will disable the irq).
> >
> > This patch fixes this issue by using console_flush_on_panic()
> > to flush to console.
> > 
> > After this patch, we can see all the log since the nmi_panic
> > in the panic console.
> 
> This is not a good idea. The crashdump is the best source of
> information about the crashed system. It includes the complete
> log.
okay.

Sometimes, we cannot get the crashdump file, so any log is important
to us.

> 
> The system is in unknown state during panic(). Any operation
> might break. Flushing consoles increases the risk that
> the crashdump will not get generated. The crashdump is more
> important. If the crashdump succeeds than the consoles are
> not needed.
> 
> Note that printk() does not handle consoles in NMI because it might
> cause deadlock. console_flush_on_panic() tries to avoid deadlock
> caused by console_sem. Also the particular console drivers are
> more careful because oops_in_progress is set at this stage.
> But there is still a risk of the deadlock. There might be another
> locks that are do not check oops_in_progress. Also a potential
> double unlock might cause deadlock.
okay, thanks for the detail explanations.

> 
> IMHO, the main motivation for this patch was to flush the per-CPU
> printk buffers (v1). But it is not longer needed. The buffers
> were removed in 5.15-rc1, see the commit 93d102f094be9beab28e
> ("printk: remove safe buffers").
> 
> The only reason to call console drivers when crashdump is generated
> is to debug the kexec code path. But I am not sure if
> console_flush_on_panic() would help here. The kexec might fail
> anytime before or after this flush so that the important
> messages will not be visible anyway. John Ogness is going
> to add atomic serial console that might be better for this
> use case.
I hope it is ready as soon as possible..

Thanks
Huang Shijie