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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,LH_URI_DOM_IN_PATH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14025C4363D for ; Thu, 24 Sep 2020 16:26:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D157C23741 for ; Thu, 24 Sep 2020 16:26:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727460AbgIXQ0K (ORCPT ); Thu, 24 Sep 2020 12:26:10 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:57004 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726645AbgIXQ0K (ORCPT ); Thu, 24 Sep 2020 12:26:10 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kLU4L-00ENPr-R1; Thu, 24 Sep 2020 10:26:05 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:40828 helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1kLU4K-0000tJ-La; Thu, 24 Sep 2020 10:26:05 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Michael Kelley Cc: Konrad Rzeszutek Wilk , Dave Young , Andrew Morton , "bhe\@redhat.com" , "linux-kernel\@vger.kernel.org" , "kexec\@lists.infradead.org" , Eric DeVolder , Boris Ostrovsky , Tianyu Lan , Wei Liu , Masami Hiramatsu , HATAYAMA Daisuke References: <20200918032546.GA4180@dhcp-128-65.nay.redhat.com> <20200918174743.0994c59f058451948837dcb6@linux-foundation.org> <20200921201811.GB3437@char.us.oracle.com> <87v9g6fuub.fsf@x220.int.ebiederm.org> <20200923024329.GB3642@dhcp-128-65.nay.redhat.com> <20200923154825.GC7635@char.us.oracle.com> Date: Thu, 24 Sep 2020 11:25:31 -0500 In-Reply-To: (Michael Kelley's message of "Thu, 24 Sep 2020 16:15:03 +0000") Message-ID: <874knndtvo.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kLU4K-0000tJ-La;;;mid=<874knndtvo.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18JVMPiun/wIfdY3BUVFG/zMkK+3mTcQDU= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] Only allow to set crash_kexec_post_notifiers on boot time X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael Kelley writes: > From: Konrad Rzeszutek Wilk Sent: Wednesday, September 23, 2020 8:48 AM >> >> On Wed, Sep 23, 2020 at 10:43:29AM +0800, Dave Young wrote: >> > + more people who may care about this param >> >> Paarty time!! >> >> (See below, didn't snip any comments) >> > On 09/21/20 at 08:45pm, Eric W. Biederman wrote: >> > > Konrad Rzeszutek Wilk writes: >> > > >> > > > On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote: >> > > >> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote: >> > > >> >> > > >> > crash_kexec_post_notifiers enables running various panic notifier >> > > >> > before kdump kernel booting. This increases risks of kdump failure. >> > > >> > It is well documented in kernel-parameters.txt. We do not suggest >> > > >> > people to enable it together with kdump unless he/she is really sure. >> > > >> > This is also not suggested to be enabled by default when users are >> > > >> > not aware in distributions. >> > > >> > >> > > >> > But unfortunately it is enabled by default in systemd, see below >> > > >> > discussions in a systemd report, we can not convince systemd to change >> > > >> > it: >> > > >> > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsyst >> emd%2Fsystemd%2Fissues%2F16661&data=02%7C01%7Cmikelley%40microsoft.com% >> 7C3631bae06f7147c0f92908d85fd7f2b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% >> 7C637364728378052956&sdata=9CUpPUxcKLLggbJ1bjubBjbFUAhPVeZhIc4yss8wAiU%3 >> D&reserved=0 >> > > >> > >> > > >> > Actually we have got reports about kdump kernel hangs in both s390x >> > > >> > and powerpcle cases caused by the systemd change, also some x86 cases >> > > >> > could also be caused by the same (although that is in Hyper-V code >> > > >> > instead of systemd, that need to be addressed separately). >> > > > >> > > > Perhaps it may be better to fix the issus on s390x and PowerPC as well? >> > > > >> > > >> > >> > > >> > Thus to avoid the auto enablement here just disable the param writable >> > > >> > permission in sysfs. >> > > >> > >> > > >> >> > > >> Well. I don't think this is at all a desirable way of resolving a >> > > >> disagreement with the systemd developers >> > > >> >> > > >> At the above github address I'm seeing "ryncsn added a commit to >> > > >> ryncsn/systemd that referenced this issue 9 days ago", "pstore: don't >> > > >> enable crash_kexec_post_notifiers by default". So didn't that address >> > > >> the issue? >> > > > >> > > > It does in systemd, but there is a strong interest in making this on >> > > > by default. >> > > >> > > There is also a strong interest in removing this code entirely from the >> > > kernel. >> > >> > Added Hyper-V people and people who created the param, it is below >> > commit, I also want to remove it if possible, let's see how people >> > think, but the least way should be to disable the auto setting in both systemd >> > and kernel: > > Hyper-V uses a notifier to inform the host system that a Linux VM has > panic'ed. Informing the host is particularly important in a public cloud > such as Azure so that the cloud software can alert the customer, and can > track cloud-wide reliability statistics. Whether a kdump is taken is controlled > entirely by the customer and how he configures the VM, and we want > the host to be informed either way. Why? Why does the host care? Especially if the VM continues executing into a kdump kernel? Further like I have mentioned everytime something like this has come up a call on the kexec on panic code path should be a direct call (That can be audited) not something hidden in a notifier call chain (which can not). Eric