Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3613718rwb; Mon, 16 Jan 2023 10:16:39 -0800 (PST) X-Google-Smtp-Source: AMrXdXtxcJy9oUjQ7ySoJ/l6pQusANknqH+WGxubUVQAzZfBArtRvSTU0mMXEhp86Xc0pbqZxEAM X-Received: by 2002:a05:6402:48d:b0:46f:d386:117d with SMTP id k13-20020a056402048d00b0046fd386117dmr11205184edv.33.1673892999091; Mon, 16 Jan 2023 10:16:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673892999; cv=none; d=google.com; s=arc-20160816; b=iGwgO/Na1VrggoFnMwGDipyU2s5MaPUqNN5tAUT3c4nwFfp74xXLe9FZ5evZQBm1NV G1Ul6NXAcuK1kNSC7I0L1wXcecONLPeY6rv7A0ldzkZKkraTgbgUyQCQLIa4SJ7QH3L3 nog9WkFfPGyEiOOEbwunYYBJOolhinL0Me07CFBRu371RWjPz/SIORw08P0eOmzbL4mL JKFaCjcTLWJ35Hi+Jt6nWx5WPUhkZVvVHN03i6u6gIeZqP24edTyABvZnn48vctjU4d5 x9KkkaaV3N19C2lLZuxdkPDGBP74g4tI2WMx5BiH1o2mUlNah3OQWF840Uohp7vHUxhI 88Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=K4v/EXD8NqVv4X/hqYMf1lKPNUH28MQhkwcMc/dXek0=; b=m34oXU27OClDR7HYmoduQjx3tTfFmJEFZxpcEX1oDdPuaHSdUYTBjx5YqVRu6c7e4r a6dwlt5eUnJRq0y+K7UhFx2jDWZ3vkcfqw5rMgcv1kSL6t8/qENOd0VxGkdbmQj+qylX LabUrXZYwlB2tHqGFskmD95KUWdllrUssT+71R9y9k2VggbHkLJq5tlo34i58lvpSW/I 9798b9mQgF8ORNw0fOJfYB02HHiAC0uQGgGl2kUy7xSdY6Lz778vk88iVb7I4yTe6m3/ hhtNd1Tqq0zlkeJ0Pb30okpofhW0MrhpqBoTihFrHx8fHouJwnG9vs6bFTaYsDbOJ+Mq s91A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tesarici.cz header.s=mail header.b=alOM8Qze; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tesarici.cz Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 10-20020a50874a000000b0047e2b42bc54si6893904edv.189.2023.01.16.10.16.27; Mon, 16 Jan 2023 10:16:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@tesarici.cz header.s=mail header.b=alOM8Qze; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tesarici.cz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233744AbjAPQmr (ORCPT + 50 others); Mon, 16 Jan 2023 11:42:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233401AbjAPQmN (ORCPT ); Mon, 16 Jan 2023 11:42:13 -0500 Received: from bee.tesarici.cz (bee.tesarici.cz [77.93.223.253]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FB4B3E603 for ; Mon, 16 Jan 2023 08:30:12 -0800 (PST) Received: from meshulam.tesarici.cz (dynamic-2a00-1028-83b8-1e7a-b985-910f-39e1-703f.ipv6.o2.cz [IPv6:2a00:1028:83b8:1e7a:b985:910f:39e1:703f]) (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 bee.tesarici.cz (Postfix) with ESMTPSA id E0D0413E0C9; Mon, 16 Jan 2023 17:30:08 +0100 (CET) Authentication-Results: mail.tesarici.cz; dmarc=fail (p=none dis=none) header.from=tesarici.cz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tesarici.cz; s=mail; t=1673886609; bh=EWAvrD4RojL0LVOAIJLliUiQp4sAh2O0X95WyClxam4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=alOM8Qzex40r+j9quWCOGy7tiIciq8Q7+8fiyc9/pZhoxFF5X9wUKW3NqU+Iaq7p6 KTq6Qtohzbxc0PzE/MYr3dh7tf5HLtLEgZT1nUAC/zHWMSubGnajgAAgxK8TRiObis G79qPHNI/lz08EJ9YJBczwh6sM5qfg7MxLxKlOCD/2tjLUjtoibZQaBH8v2SHAKYhd fUDUzxjcAN/l7nU9lijkPyZY+eZ/YYDyWchZBnZ4BF/VldaIFy+tGTwKkYixVn4zjn svympXbsTq8lyZUVakVP6liCaCU9Bo1OblIWUdR/3JR4PQ30FnveEN58ml2GozYFIL xKShC5ULUX+fw== Date: Mon, 16 Jan 2023 17:30:05 +0100 From: Petr =?UTF-8?B?VGVzYcWZw61r?= To: Eric DeVolder Cc: Sourabh Jain , linux-kernel@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, ebiederm@xmission.com, dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, nramas@linux.microsoft.com, thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de, rppt@kernel.org, david@redhat.com, konrad.wilk@oracle.com, boris.ostrovsky@oracle.com Subject: Re: [PATCH v15 1/7] crash: move crash_prepare_elf64_headers() Message-ID: <20230116173005.21bd7b67@meshulam.tesarici.cz> In-Reply-To: References: <20221209153656.3284-1-eric.devolder@oracle.com> <20221209153656.3284-2-eric.devolder@oracle.com> <09567e13-c5ed-d1b9-027c-9340fce6a0a8@linux.ibm.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.35; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On Thu, 12 Jan 2023 11:23:18 -0600 Eric DeVolder wrote: >[...] > After looking into this for a bit, to allow hotplug without kexec_file would require quite a bit of > code movement. Why? Because hotplug is basically built on top of (part of) the infrastructure that > was needed for kexec_file. > > I'd be inclined to suggest that KEXEC_FILE be a required dependency for CRASH_HOTPLUG, ie: > > config CRASH_HOTPLUG > bool "Update the crash elfcorehdr on system configuration changes" > default n > - depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG) > + depends on CRASH_DUMP && KEXEC_FILE && (HOTPLUG_CPU || MEMORY_HOTPLUG) > > > If that isn't feasible, then it would appear quite a bit of surgery is needed to properly separate > out the items hotplug needs from kexec_file. > > Thoughts? I would have thought that CPU hotplug can be handled in the kernel only if the crash image was loaded by the kernel with kexec_file_load(2). When the image is loaded with kexec_load(2), then all data structures are prepared by the user-space utility kexec(8), and the kernel generally has no idea how to handle them. In short, I believe that by definition there must be this dependency of CRASH_HOTPLUG on KEXEC_FILE. Petr T