From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BwWuuSDS" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DCF2DD for ; Wed, 22 Nov 2023 01:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700645683; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+OTgZltwB2ZS+YZyn6PYgFPXeR3pdRlWkz0aWS8O4HE=; b=BwWuuSDSvBZX8Mo7G/uzuxwxVixnrmmdqUnkZx0OtwE1DVMH27AH4c6jJvXbP/BVBm2pnd 77sZlTm5mtm89rkaBPL3o9nnd+bXlfVH6dL/cYz2vincEezSthdFNVSkUO8hR+dnyun2so bzfx4LydAh4Vj2wfqlYfnQ+tbldTuWc= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-_biuZLCONCOAsgDXiclx4A-1; Wed, 22 Nov 2023 04:34:40 -0500 X-MC-Unique: _biuZLCONCOAsgDXiclx4A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8960E3C0FCA6; Wed, 22 Nov 2023 09:34:39 +0000 (UTC) Received: from localhost (unknown [10.72.112.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A80F1C060AE; Wed, 22 Nov 2023 09:34:36 +0000 (UTC) Date: Wed, 22 Nov 2023 17:34:33 +0800 From: Baoquan He To: Ignat Korchagin Cc: eric_devolder@yahoo.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org, geert@linux-m68k.org, tsbogend@alpha.franken.de, James Bottomley , deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org, glaubitz@physik.fu-berlin.de, Thomas Gleixner , Ingo Molnar , Borislav Petkov , dave.hansen@linux.intel.com, x86@kernel.org, linux-kernel , linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, kernel@xen0n.name, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com, keescook@chromium.org, paulmck@kernel.org, Peter Zijlstra , frederic@kernel.org, Andrew Morton , Ard Biesheuvel , samitolvanen@google.com, juerg.haefliger@canonical.com, arnd@arndb.de, rmk+kernel@armlinux.org.uk, linus.walleij@linaro.org, sebastian.reichel@collabora.com, rppt@kernel.org, kirill.shutemov@linux.intel.com, anshuman.khandual@arm.com, ziy@nvidia.com, masahiroy@kernel.org, ndesaulniers@google.com, mhiramat@kernel.org, ojeda@kernel.org, thunder.leizhen@huawei.com, xin3.li@intel.com, tj@kernel.org, Greg KH , tsi@tuyoix.net, hbathini@linux.ibm.com, sourabhjain@linux.ibm.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, kernel-team Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec") Message-ID: References: Precedence: bulk X-Mailing-List: linux-ia64@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 On 11/21/23 at 09:43am, Ignat Korchagin wrote: > On Tue, Nov 21, 2023 at 7:53 AM Ignat Korchagin wrote: > > > > On Tue, Nov 21, 2023 at 1:50 AM Baoquan He wrote: > > > > > > Eric DeVolder's Oracle mail address is not available anymore, add his > > > current mail address he told me. > > > > Thank you! > > > > > On 11/20/23 at 10:52pm, Ignat Korchagin wrote: > > > > Good day! > > > > > > > > We have recently started to evaluate Linux 6.6 and noticed that we > > > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP > > > > enabled. It seems to be related to commit 89cde455 ("kexec: > > > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where > > > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP. > > > > > > > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE > > > > with enforced signature check to support the kernel crash dumping > > > > functionality and would like to keep CONFIG_KEXEC disabled for > > > > security reasons [1]. > > > > > > > > I was reading the long commit message, but the reason for adding > > > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I > > > > believe from the implementation perspective CONFIG_KEXEC_FILE should > > > > suffice here (as we successfully used it for crashdumps on Linux 6.1). > > > > > > > > Is there a reason for adding this dependency or is it just an > > > > oversight? Would some solution of requiring either CONFIG_KEXEC or > > > > CONFIG_KEXEC_FILE work here? > > > > > > I searched the patch history, found Eric didn't add the dependency on > > > CONFIG_KEXEC at the beginning. Later a linux-next building failure with > > > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while > > > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for > > > CRASH_DUMP. Please see below link for more details: > > > > > > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u > > > > Thank you for digging this up. However I'm still confused, because > > this is exactly how we configure Linux 6.1 (although we do have > > CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe > > we did not investigate this issue properly. > > I did some preliminary investigation for this. If I patch out the > dependency on CONFIG_KEXEC the kernel builds just fine for x86 > (without CONFIG_CRASH_HOTPLUG - which is probably another issue) - so > this was the previous behaviour. I can see that the reported error is > for arm architecture and was able to reproduce it with a simple cross > compiler in Debian. However, I think it is still somehow related to > this patchset as the previous kernels (up to 6.5) build fine with just > CONFIG_CRASH_DUMP and without CONFIG_KEXEC for arm as well. So even > for arm it was introduced in 6.6. Thanks for the information. I haven't run the reproducer of issue reported on Eric's old patchset, while checkout to kernel 6.1, only s390 selected KEXEC for CRASH_DUMP already. And with the ARM building breakage, the simplest idea is to select KEXEC only for ARM or S390 CRASH_DUMP. I plan to try the reproducer later. If you have any idea or draft patch, please feel free to post. diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec index 7aff28ded2f4..382dcd8d7a9d 100644 --- a/kernel/Kconfig.kexec +++ b/kernel/Kconfig.kexec @@ -97,7 +97,7 @@ config CRASH_DUMP depends on ARCH_SUPPORTS_KEXEC select CRASH_CORE select KEXEC_CORE - select KEXEC + select KEXEC if (ARM || S390) arch/s390/Kconfig in kernel 6.1: config CRASH_DUMP bool "kernel crash dumps" select KEXEC help Generate crash dump after being started by kexec. Crash dump kernels are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. Refer to for more details on this. This option also enables s390 zfcpdump. See also > > > > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs > > > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when > > > cpu/memory hotplug hapened. > > > > This still feels like a regression to me: any crash dump support > > should be independent of KEXEC syscalls being present. While probably > > the common case (including us) that the crashing kernel and recovery > > kernel are the same, they don't have to be. We need kexec syscall in > > the crashing kernel, but crashdump support in the recovery kernel (but > > the recovery kernel not having the kexec syscalls should be totally > > fine). If we do require some code definitions from kexec - at most we > > should put them under CONFIG_KEXEC_CORE. > > > > > Thanks > > > Baoquan > > > > > Ignat > 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 D963BC61D9C for ; Wed, 22 Nov 2023 09:34:57 +0000 (UTC) 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U8V4IHTtFdMRxNR+JyxcfuLMHfeelqehyvYrVM+EsmU=; b=iyL85xOfl/6JiF VXUr7YmBpmZGJurSSbou8sEUxFyys8jkjTT0QREWjrH81Ce35QUijZu5W0BK2KJIFF3bA9rMk187j wVL2SsOPI2YBwMqAKktNRBCkZDATM8nktYIS5VOMcOhJvAcPTDrX9/RWPtxcDLy8twY6FYPu26559 J1RdjLQe6iz3L+/WnqBYkZVQYOFMNhzuG+wyyz0PzpZ4c07Hqvk4ya//5SM4aj+TVBrDwRKmb952o WYkSmhd3uqut+X/AK0XnAIKSdTVvA3jp+Gb5rRS9hicG4+YbxpBRYQo6Gx91DjD1EACrxSyeyqtIq 7mHnlM4S29ijffZieNSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5jdF-001E8B-0A; Wed, 22 Nov 2023 09:34:53 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5jdB-001E6l-2A for linux-riscv@lists.infradead.org; Wed, 22 Nov 2023 09:34:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700645684; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+OTgZltwB2ZS+YZyn6PYgFPXeR3pdRlWkz0aWS8O4HE=; b=AyZdLpZ8AiKvLQrSXIR6OO2LShWad9447dErRDr6JDn9GXz4ajw8Wi/aqA6TjEWZnIF+o3 n4O1wCzZYsmXkZzsGZJECPH5MRhOtEsuMWOrmekZIG6ZSpfq1+pR/5TbSBum39W9BIPA3i o53o/XjeGQcrCAx8QK19U9zi7vRdekg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-_biuZLCONCOAsgDXiclx4A-1; Wed, 22 Nov 2023 04:34:40 -0500 X-MC-Unique: _biuZLCONCOAsgDXiclx4A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8960E3C0FCA6; Wed, 22 Nov 2023 09:34:39 +0000 (UTC) Received: from localhost (unknown [10.72.112.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A80F1C060AE; Wed, 22 Nov 2023 09:34:36 +0000 (UTC) Date: Wed, 22 Nov 2023 17:34:33 +0800 From: Baoquan He To: Ignat Korchagin Cc: eric_devolder@yahoo.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org, geert@linux-m68k.org, tsbogend@alpha.franken.de, James Bottomley , deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org, glaubitz@physik.fu-berlin.de, Thomas Gleixner , Ingo Molnar , Borislav Petkov , dave.hansen@linux.intel.com, x86@kernel.org, linux-kernel , linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, kernel@xen0n.name, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com, keescook@chromium.org, paulmck@kernel.org, Peter Zijlstra , frederic@kernel.org, Andrew Morton , Ard Biesheuvel , samitolvanen@google.com, juerg.haefliger@canonical.com, arnd@arndb.de, rmk+kernel@armlinux.org.uk, linus.walleij@linaro.org, sebastian.reichel@collabora.com, rppt@kernel.org, kirill.shutemov@linux.intel.com, anshuman.khandual@arm.com, ziy@nvidia.com, masahiroy@kernel.org, ndesaulniers@google.com, mhiramat@kernel.org, ojeda@kernel.org, thunder.leizhen@huawei.com, xin3.li@intel.com, tj@kernel.org, Greg KH , tsi@tuyoix.net, hbathini@linux.ibm.com, sourabhjain@linux.ibm.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, kernel-team Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec") Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231122_013449_785343_55E3EB21 X-CRM114-Status: GOOD ( 48.45 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gMTEvMjEvMjMgYXQgMDk6NDNhbSwgSWduYXQgS29yY2hhZ2luIHdyb3RlOgo+IE9uIFR1ZSwg Tm92IDIxLCAyMDIzIGF0IDc6NTPigK9BTSBJZ25hdCBLb3JjaGFnaW4gPGlnbmF0QGNsb3VkZmxh cmUuY29tPiB3cm90ZToKPiA+Cj4gPiBPbiBUdWUsIE5vdiAyMSwgMjAyMyBhdCAxOjUw4oCvQU0g QmFvcXVhbiBIZSA8YmhlQHJlZGhhdC5jb20+IHdyb3RlOgo+ID4gPgo+ID4gPiBFcmljIERlVm9s ZGVyJ3MgT3JhY2xlIG1haWwgYWRkcmVzcyBpcyBub3QgYXZhaWxhYmxlIGFueW1vcmUsIGFkZCBo aXMKPiA+ID4gY3VycmVudCBtYWlsIGFkZHJlc3MgaGUgdG9sZCBtZS4KPiA+Cj4gPiBUaGFuayB5 b3UhCj4gPgo+ID4gPiBPbiAxMS8yMC8yMyBhdCAxMDo1MnBtLCBJZ25hdCBLb3JjaGFnaW4gd3Jv dGU6Cj4gPiA+ID4gR29vZCBkYXkhCj4gPiA+ID4KPiA+ID4gPiBXZSBoYXZlIHJlY2VudGx5IHN0 YXJ0ZWQgdG8gZXZhbHVhdGUgTGludXggNi42IGFuZCBub3RpY2VkIHRoYXQgd2UKPiA+ID4gPiBj YW5ub3QgZGlzYWJsZSBDT05GSUdfS0VYRUMgYW55bW9yZSwgYnV0IGtlZXAgQ09ORklHX0NSQVNI X0RVTVAKPiA+ID4gPiBlbmFibGVkLiBJdCBzZWVtcyB0byBiZSByZWxhdGVkIHRvIGNvbW1pdCA4 OWNkZTQ1NSAoImtleGVjOgo+ID4gPiA+IGNvbnNvbGlkYXRlIGtleGVjIGFuZCBjcmFzaCBvcHRp b25zIGludG8ga2VybmVsL0tjb25maWcua2V4ZWMiKSwgd2hlcmUKPiA+ID4gPiBhIENPTkZJR19L RVhFQyBkZXBlbmRlbmN5IHdhcyBhZGRlZCB0byBDT05GSUdfQ1JBU0hfRFVNUC4KPiA+ID4gPgo+ ID4gPiA+IEluIG91ciBjdXJyZW50IGtlcm5lbCAoTGludXggNi4xKSB3ZSBvbmx5IGVuYWJsZSBD T05GSUdfS0VYRUNfRklMRQo+ID4gPiA+IHdpdGggZW5mb3JjZWQgc2lnbmF0dXJlIGNoZWNrIHRv IHN1cHBvcnQgdGhlIGtlcm5lbCBjcmFzaCBkdW1waW5nCj4gPiA+ID4gZnVuY3Rpb25hbGl0eSBh bmQgd291bGQgbGlrZSB0byBrZWVwIENPTkZJR19LRVhFQyBkaXNhYmxlZCBmb3IKPiA+ID4gPiBz ZWN1cml0eSByZWFzb25zIFsxXS4KPiA+ID4gPgo+ID4gPiA+IEkgd2FzIHJlYWRpbmcgdGhlIGxv bmcgY29tbWl0IG1lc3NhZ2UsIGJ1dCB0aGUgcmVhc29uIGZvciBhZGRpbmcKPiA+ID4gPiBDT05G SUdfS0VYRUMgYXMgYSBkZXBlbmRlbmN5IGZvciBDT05GSUdfQ1JBU0hfRFVNUCBldmFkZWQgbWUu IEFuZCBJCj4gPiA+ID4gYmVsaWV2ZSBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2 ZSBDT05GSUdfS0VYRUNfRklMRSBzaG91bGQKPiA+ID4gPiBzdWZmaWNlIGhlcmUgKGFzIHdlIHN1 Y2Nlc3NmdWxseSB1c2VkIGl0IGZvciBjcmFzaGR1bXBzIG9uIExpbnV4IDYuMSkuCj4gPiA+ID4K PiA+ID4gPiBJcyB0aGVyZSBhIHJlYXNvbiBmb3IgYWRkaW5nIHRoaXMgZGVwZW5kZW5jeSBvciBp cyBpdCBqdXN0IGFuCj4gPiA+ID4gb3ZlcnNpZ2h0PyBXb3VsZCBzb21lIHNvbHV0aW9uIG9mIHJl cXVpcmluZyBlaXRoZXIgQ09ORklHX0tFWEVDIG9yCj4gPiA+ID4gQ09ORklHX0tFWEVDX0ZJTEUg d29yayBoZXJlPwo+ID4gPgo+ID4gPiBJIHNlYXJjaGVkIHRoZSBwYXRjaCBoaXN0b3J5LCBmb3Vu ZCBFcmljIGRpZG4ndCBhZGQgdGhlIGRlcGVuZGVuY3kgb24KPiA+ID4gQ09ORklHX0tFWEVDIGF0 IHRoZSBiZWdpbm5pbmcuIExhdGVyIGEgbGludXgtbmV4dCBidWlsZGluZyBmYWlsdXJlIHdpdGgK PiA+ID4gcmFuZGNvbmZpZyB3YXMgcmVwb3J0ZWQsIGluIHRoZXJlIENPTkZJR19DUkFTSF9EVU1Q IGVuYWJsZWQsIHdoaWxlCj4gPiA+IENPTkZJR19LRVhFQyBpcyBkaXNhYmxlZC4gRmluYWxseSBF cmljIGFkZGVkIHRoZSBLRVhFQyBkZXBlbmRlbmN5IGZvcgo+ID4gPiBDUkFTSF9EVU1QLiBQbGVh c2Ugc2VlIGJlbG93IGxpbmsgZm9yIG1vcmUgZGV0YWlsczoKPiA+ID4KPiA+ID4gaHR0cHM6Ly9s b3JlLmtlcm5lbC5vcmcvYWxsLzNlOGVlY2QxLWEyNzctMmNmYi02OTBlLTVkZTJlYjdiOTg4ZUBv cmFjbGUuY29tL1QvI3UKPiA+Cj4gPiBUaGFuayB5b3UgZm9yIGRpZ2dpbmcgdGhpcyB1cC4gSG93 ZXZlciBJJ20gc3RpbGwgY29uZnVzZWQsIGJlY2F1c2UKPiA+IHRoaXMgaXMgZXhhY3RseSBob3cg d2UgY29uZmlndXJlIExpbnV4IDYuMSAoYWx0aG91Z2ggd2UgZG8gaGF2ZQo+ID4gQ09ORklHX0tF WEVDX0ZJTEUgZW5hYmxlZCkgYW5kIHdlIGRvbid0IGhhdmUgYW55IHByb2JsZW1zLiBJIGJlbGll dmUKPiA+IHdlIGRpZCBub3QgaW52ZXN0aWdhdGUgdGhpcyBpc3N1ZSBwcm9wZXJseS4KPiAKPiBJ IGRpZCBzb21lIHByZWxpbWluYXJ5IGludmVzdGlnYXRpb24gZm9yIHRoaXMuIElmIEkgcGF0Y2gg b3V0IHRoZQo+IGRlcGVuZGVuY3kgb24gQ09ORklHX0tFWEVDIHRoZSBrZXJuZWwgYnVpbGRzIGp1 c3QgZmluZSBmb3IgeDg2Cj4gKHdpdGhvdXQgQ09ORklHX0NSQVNIX0hPVFBMVUcgLSB3aGljaCBp cyBwcm9iYWJseSBhbm90aGVyIGlzc3VlKSAtIHNvCj4gdGhpcyB3YXMgdGhlIHByZXZpb3VzIGJl aGF2aW91ci4gSSBjYW4gc2VlIHRoYXQgdGhlIHJlcG9ydGVkIGVycm9yIGlzCj4gZm9yIGFybSBh cmNoaXRlY3R1cmUgYW5kIHdhcyBhYmxlIHRvIHJlcHJvZHVjZSBpdCB3aXRoIGEgc2ltcGxlIGNy b3NzCj4gY29tcGlsZXIgaW4gRGViaWFuLiBIb3dldmVyLCBJIHRoaW5rIGl0IGlzIHN0aWxsIHNv bWVob3cgcmVsYXRlZCB0bwo+IHRoaXMgcGF0Y2hzZXQgYXMgdGhlIHByZXZpb3VzIGtlcm5lbHMg KHVwIHRvIDYuNSkgYnVpbGQgZmluZSB3aXRoIGp1c3QKPiBDT05GSUdfQ1JBU0hfRFVNUCBhbmQg d2l0aG91dCBDT05GSUdfS0VYRUMgZm9yIGFybSBhcyB3ZWxsLiBTbyBldmVuCj4gZm9yIGFybSBp dCB3YXMgaW50cm9kdWNlZCBpbiA2LjYuCgpUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbi4KCkkg aGF2ZW4ndCBydW4gdGhlIHJlcHJvZHVjZXIgb2YgaXNzdWUgcmVwb3J0ZWQgb24gRXJpYydzIG9s ZCBwYXRjaHNldCwKd2hpbGUgY2hlY2tvdXQgdG8ga2VybmVsIDYuMSwgb25seSBzMzkwIHNlbGVj dGVkIEtFWEVDIGZvciBDUkFTSF9EVU1QCmFscmVhZHkuIEFuZCB3aXRoIHRoZSBBUk0gYnVpbGRp bmcgYnJlYWthZ2UsIHRoZSBzaW1wbGVzdCBpZGVhIGlzIAp0byBzZWxlY3QgS0VYRUMgb25seSBm b3IgQVJNIG9yIFMzOTAgQ1JBU0hfRFVNUC4gSSBwbGFuIHRvIHRyeSB0aGUKcmVwcm9kdWNlciBs YXRlci4gSWYgeW91IGhhdmUgYW55IGlkZWEgb3IgZHJhZnQgcGF0Y2gsIHBsZWFzZSBmZWVsIGZy ZWUKdG8gcG9zdC4KCmRpZmYgLS1naXQgYS9rZXJuZWwvS2NvbmZpZy5rZXhlYyBiL2tlcm5lbC9L Y29uZmlnLmtleGVjCmluZGV4IDdhZmYyOGRlZDJmNC4uMzgyZGNkOGQ3YTlkIDEwMDY0NAotLS0g YS9rZXJuZWwvS2NvbmZpZy5rZXhlYworKysgYi9rZXJuZWwvS2NvbmZpZy5rZXhlYwpAQCAtOTcs NyArOTcsNyBAQCBjb25maWcgQ1JBU0hfRFVNUAogICAgICAgIGRlcGVuZHMgb24gQVJDSF9TVVBQ T1JUU19LRVhFQwogICAgICAgIHNlbGVjdCBDUkFTSF9DT1JFCiAgICAgICAgc2VsZWN0IEtFWEVD X0NPUkUKLSAgICAgICBzZWxlY3QgS0VYRUMKKyAgICAgICBzZWxlY3QgS0VYRUMgaWYgKEFSTSB8 fCBTMzkwKQoKCmFyY2gvczM5MC9LY29uZmlnIGluIGtlcm5lbCA2LjE6CmNvbmZpZyBDUkFTSF9E VU1QCiAgICAgICAgYm9vbCAia2VybmVsIGNyYXNoIGR1bXBzIgogICAgICAgIHNlbGVjdCBLRVhF QwogICAgICAgIGhlbHAKICAgICAgICAgIEdlbmVyYXRlIGNyYXNoIGR1bXAgYWZ0ZXIgYmVpbmcg c3RhcnRlZCBieSBrZXhlYy4KICAgICAgICAgIENyYXNoIGR1bXAga2VybmVscyBhcmUgbG9hZGVk IGluIHRoZSBtYWluIGtlcm5lbCB3aXRoIGtleGVjLXRvb2xzCiAgICAgICAgICBpbnRvIGEgc3Bl Y2lhbGx5IHJlc2VydmVkIHJlZ2lvbiBhbmQgdGhlbiBsYXRlciBleGVjdXRlZCBhZnRlcgogICAg ICAgICAgYSBjcmFzaCBieSBrZHVtcC9rZXhlYy4KICAgICAgICAgIFJlZmVyIHRvIDxmaWxlOkRv Y3VtZW50YXRpb24vczM5MC96ZmNwZHVtcC5yc3Q+IGZvciBtb3JlIGRldGFpbHMgb24gdGhpcy4K ICAgICAgICAgIFRoaXMgb3B0aW9uIGFsc28gZW5hYmxlcyBzMzkwIHpmY3BkdW1wLgogICAgICAg ICAgU2VlIGFsc28gPGZpbGU6RG9jdW1lbnRhdGlvbi9zMzkwL3pmY3BkdW1wLnJzdD4KCj4gCj4g PiA+IEFuZCBiZXNpZGVzLCB0aGUgbmV3bHkgYWRkZWQgQ09ORklHX0NSQVNIX0hPVFBMVUcgYWxz byBuZWVkcwo+ID4gPiBDT05GSUdfS0VYRUMgaWYgdGhlIGVsZmNvcmVoZHIgaXMgYWxsb3dlZCB0 byBiZSBtYW5pcHVsYXRlZCB3aGVuCj4gPiA+IGNwdS9tZW1vcnkgaG90cGx1ZyBoYXBlbmVkLgo+ ID4KPiA+IFRoaXMgc3RpbGwgZmVlbHMgbGlrZSBhIHJlZ3Jlc3Npb24gdG8gbWU6IGFueSBjcmFz aCBkdW1wIHN1cHBvcnQKPiA+IHNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiBLRVhFQyBzeXNjYWxs cyBiZWluZyBwcmVzZW50LiBXaGlsZSBwcm9iYWJseQo+ID4gdGhlIGNvbW1vbiBjYXNlIChpbmNs dWRpbmcgdXMpIHRoYXQgdGhlIGNyYXNoaW5nIGtlcm5lbCBhbmQgcmVjb3ZlcnkKPiA+IGtlcm5l bCBhcmUgdGhlIHNhbWUsIHRoZXkgZG9uJ3QgaGF2ZSB0byBiZS4gV2UgbmVlZCBrZXhlYyBzeXNj YWxsIGluCj4gPiB0aGUgY3Jhc2hpbmcga2VybmVsLCBidXQgY3Jhc2hkdW1wIHN1cHBvcnQgaW4g dGhlIHJlY292ZXJ5IGtlcm5lbCAoYnV0Cj4gPiB0aGUgcmVjb3Zlcnkga2VybmVsIG5vdCBoYXZp bmcgdGhlIGtleGVjIHN5c2NhbGxzIHNob3VsZCBiZSB0b3RhbGx5Cj4gPiBmaW5lKS4gSWYgd2Ug ZG8gcmVxdWlyZSBzb21lIGNvZGUgZGVmaW5pdGlvbnMgZnJvbSBrZXhlYyAtIGF0IG1vc3Qgd2UK PiA+IHNob3VsZCBwdXQgdGhlbSB1bmRlciBDT05GSUdfS0VYRUNfQ09SRS4KPiA+Cj4gPiA+IFRo YW5rcwo+ID4gPiBCYW9xdWFuCj4gPiA+Cj4gCj4gSWduYXQKPiAKCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1yaXNjdiBtYWlsaW5nIGxpc3QK bGludXgtcmlzY3ZAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJpc2N2Cg== 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 F02D8C61D99 for ; Wed, 22 Nov 2023 16:47:47 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AyZdLpZ8; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AyZdLpZ8; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Sb6cL49Swz3clH for ; Thu, 23 Nov 2023 03:47:46 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AyZdLpZ8; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AyZdLpZ8; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=bhe@redhat.com; receiver=lists.ozlabs.org) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4SZx0p3pVKz3c5S for ; Wed, 22 Nov 2023 20:34:49 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700645684; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+OTgZltwB2ZS+YZyn6PYgFPXeR3pdRlWkz0aWS8O4HE=; b=AyZdLpZ8AiKvLQrSXIR6OO2LShWad9447dErRDr6JDn9GXz4ajw8Wi/aqA6TjEWZnIF+o3 n4O1wCzZYsmXkZzsGZJECPH5MRhOtEsuMWOrmekZIG6ZSpfq1+pR/5TbSBum39W9BIPA3i o53o/XjeGQcrCAx8QK19U9zi7vRdekg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700645684; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+OTgZltwB2ZS+YZyn6PYgFPXeR3pdRlWkz0aWS8O4HE=; b=AyZdLpZ8AiKvLQrSXIR6OO2LShWad9447dErRDr6JDn9GXz4ajw8Wi/aqA6TjEWZnIF+o3 n4O1wCzZYsmXkZzsGZJECPH5MRhOtEsuMWOrmekZIG6ZSpfq1+pR/5TbSBum39W9BIPA3i o53o/XjeGQcrCAx8QK19U9zi7vRdekg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-_biuZLCONCOAsgDXiclx4A-1; Wed, 22 Nov 2023 04:34:40 -0500 X-MC-Unique: _biuZLCONCOAsgDXiclx4A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8960E3C0FCA6; Wed, 22 Nov 2023 09:34:39 +0000 (UTC) Received: from localhost (unknown [10.72.112.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A80F1C060AE; Wed, 22 Nov 2023 09:34:36 +0000 (UTC) Date: Wed, 22 Nov 2023 17:34:33 +0800 From: Baoquan He To: Ignat Korchagin Subject: Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec") Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mailman-Approved-At: Thu, 23 Nov 2023 03:46:57 +1100 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: chenhuacai@kernel.org, linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , catalin.marinas@arm.com, linus.walleij@linaro.org, dave.hansen@linux.intel.com, linux-mips@vger.kernel.org, James Bottomley , dalias@libc.org, eric_devolder@yahoo.com, linux-riscv@lists.infradead.org, will@kernel.org, kernel@xen0n.name, tsi@tuyoix.net, linux-s390@vger.kernel.org, agordeev@linux.ibm.com, rmk+kernel@armlinux.org.uk, hpa@zytor.com, paulmck@kernel.org, ysato@users.sourceforge.jp, kernel-team , deller@gmx.de, x86@kernel.org, linux@armlinux.org.uk, paul.walmsley@sifive.com, Ingo Molnar , geert@linux-m68k.org, hbathini@linux.ibm.com, samitolvanen@google.com, ojeda@kernel.org, juerg.haefliger@canonical.com, borntraeger@linux.ibm.com, frederic@kernel.org, arnd@arndb.de, mhiramat@kernel.org, Ard Biesheuvel , thunder.leizhen@huawei.com, aou@eecs.berkeley.edu, keescook@chromium.org, gor@linux.ibm.com, anshuman.khandual@arm.com, hca@linux.ibm.com, xin3.li@intel.com, npiggin@gmail.com, konrad.wilk@oracle.com, linux-m68k@lists.linux-m68k.org, Borislav Petkov , loongarch@lists.linux.dev, glaubitz@physik.fu-berlin.de, Thomas Gleixner , ziy@nvidia.com, linux-arm-kernel@lists.infradead.org, boris.ostrovsky@oracle.com, tsbogend@alpha.franken.de, sebastian.reichel@collabora.com, linux-parisc@vger.kernel.org, Greg KH , kirill.shutemov@linux.intel.com, ndesaulniers@google.com, linux-kernel , sourabhjain@linux.ibm.com, palmer@dabbelt.com, svens@linux.ibm.com, tj@kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, masahiroy@kernel.org, rppt@kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 11/21/23 at 09:43am, Ignat Korchagin wrote: > On Tue, Nov 21, 2023 at 7:53 AM Ignat Korchagin wrote: > > > > On Tue, Nov 21, 2023 at 1:50 AM Baoquan He wrote: > > > > > > Eric DeVolder's Oracle mail address is not available anymore, add his > > > current mail address he told me. > > > > Thank you! > > > > > On 11/20/23 at 10:52pm, Ignat Korchagin wrote: > > > > Good day! > > > > > > > > We have recently started to evaluate Linux 6.6 and noticed that we > > > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP > > > > enabled. It seems to be related to commit 89cde455 ("kexec: > > > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where > > > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP. > > > > > > > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE > > > > with enforced signature check to support the kernel crash dumping > > > > functionality and would like to keep CONFIG_KEXEC disabled for > > > > security reasons [1]. > > > > > > > > I was reading the long commit message, but the reason for adding > > > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I > > > > believe from the implementation perspective CONFIG_KEXEC_FILE should > > > > suffice here (as we successfully used it for crashdumps on Linux 6.1). > > > > > > > > Is there a reason for adding this dependency or is it just an > > > > oversight? Would some solution of requiring either CONFIG_KEXEC or > > > > CONFIG_KEXEC_FILE work here? > > > > > > I searched the patch history, found Eric didn't add the dependency on > > > CONFIG_KEXEC at the beginning. Later a linux-next building failure with > > > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while > > > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for > > > CRASH_DUMP. Please see below link for more details: > > > > > > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b988e@oracle.com/T/#u > > > > Thank you for digging this up. However I'm still confused, because > > this is exactly how we configure Linux 6.1 (although we do have > > CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe > > we did not investigate this issue properly. > > I did some preliminary investigation for this. If I patch out the > dependency on CONFIG_KEXEC the kernel builds just fine for x86 > (without CONFIG_CRASH_HOTPLUG - which is probably another issue) - so > this was the previous behaviour. I can see that the reported error is > for arm architecture and was able to reproduce it with a simple cross > compiler in Debian. However, I think it is still somehow related to > this patchset as the previous kernels (up to 6.5) build fine with just > CONFIG_CRASH_DUMP and without CONFIG_KEXEC for arm as well. So even > for arm it was introduced in 6.6. Thanks for the information. I haven't run the reproducer of issue reported on Eric's old patchset, while checkout to kernel 6.1, only s390 selected KEXEC for CRASH_DUMP already. And with the ARM building breakage, the simplest idea is to select KEXEC only for ARM or S390 CRASH_DUMP. I plan to try the reproducer later. If you have any idea or draft patch, please feel free to post. diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec index 7aff28ded2f4..382dcd8d7a9d 100644 --- a/kernel/Kconfig.kexec +++ b/kernel/Kconfig.kexec @@ -97,7 +97,7 @@ config CRASH_DUMP depends on ARCH_SUPPORTS_KEXEC select CRASH_CORE select KEXEC_CORE - select KEXEC + select KEXEC if (ARM || S390) arch/s390/Kconfig in kernel 6.1: config CRASH_DUMP bool "kernel crash dumps" select KEXEC help Generate crash dump after being started by kexec. Crash dump kernels are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. Refer to for more details on this. This option also enables s390 zfcpdump. See also > > > > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs > > > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when > > > cpu/memory hotplug hapened. > > > > This still feels like a regression to me: any crash dump support > > should be independent of KEXEC syscalls being present. While probably > > the common case (including us) that the crashing kernel and recovery > > kernel are the same, they don't have to be. We need kexec syscall in > > the crashing kernel, but crashdump support in the recovery kernel (but > > the recovery kernel not having the kexec syscalls should be totally > > fine). If we do require some code definitions from kexec - at most we > > should put them under CONFIG_KEXEC_CORE. > > > > > Thanks > > > Baoquan > > > > > Ignat >