Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp2677121imi; Mon, 25 Jul 2022 05:19:12 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sfqYYoyJKWZ1NyugEYiE/9rvsWfnLKapaCFjtK2NV8vQuNX03NN+8bZlDjA5UbQdbXb+Je X-Received: by 2002:a9d:3f7:0:b0:61c:9d1c:e36 with SMTP id f110-20020a9d03f7000000b0061c9d1c0e36mr4658425otf.143.1658751544924; Mon, 25 Jul 2022 05:19:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658751544; cv=none; d=google.com; s=arc-20160816; b=D71uDZWJeoffOW96iprDdlDlp5LbCn5UrKUlZbnVokJLF9VXNe+2fuiclYzvEKsJCV rrJ6AKnsZd+4NmAn3ZxPR6U0lUcgedJI/nZbkjKOcb1slrB1a/iSJaqJeqUdmuGB7SrH FbMYkI8QrE7MftQEFUHinKmJX8AXstvvWgSo3Ygsi7rsL20E3kINKhPbkmK3n54HugIJ POzwLF/KAb6Vd20N3K1/bXJSTHTXIk3W41CdRSVmvurIer5/oppa01zARP0qoDQ5KFaX /m3/uEbXU0LuGpDdHHXqn7NbV2vaAcBz7GvySZw0EjgxZiX3jRj/eOs5vOLtbrqdxZ8X d6dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PPvyHjMLA4A9n1tAA4Jqif7EHSTbfVf0ytv4zVQMZbw=; b=KUmHvKxe327B6yha1H7YSyD2LVXSPsTaSw9e2s2OpVPSIw3sfExKaNrmHDbpjL8Y7P Pp9kaGvo0+hp8fb5LxVx8hY7GJAnuVDk1Er9RLVQnU88fgxXcbIBhRw5kMNWS/3zpATZ gHZ5P+etuDZouiNSKKUQvcwq07z8p/Qk08NvdJUgVz7wnpNdSvwbPzpG2TfU/8g2HvuO cpvxWgx9X1PpP+/bHsZ1XCsPeiWYY1jY0akSPLOI9PNXAEIAcayaA8MBZPNkhZaqcvQo yr1x9ZTd/gWisCaEsthj2EKiut5QSP2ex4HJ9B3a/bwUlyj6704uyWv4tiQrGou7lVve k5eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=kmNdDbqB; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n29-20020a056870241d00b000f5cfa4ca9bsi9851376oap.209.2022.07.25.05.18.43; Mon, 25 Jul 2022 05:19:04 -0700 (PDT) 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=@zx2c4.com header.s=20210105 header.b=kmNdDbqB; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235076AbiGYMCT (ORCPT + 99 others); Mon, 25 Jul 2022 08:02:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231579AbiGYMCR (ORCPT ); Mon, 25 Jul 2022 08:02:17 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25A3416586; Mon, 25 Jul 2022 05:02:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D29F9B80E78; Mon, 25 Jul 2022 12:02:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AEE3C341C6; Mon, 25 Jul 2022 12:02:12 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="kmNdDbqB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1658750530; 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: in-reply-to:in-reply-to:references:references; bh=PPvyHjMLA4A9n1tAA4Jqif7EHSTbfVf0ytv4zVQMZbw=; b=kmNdDbqBKJxYqauSDh1rz4znS2xhBeIz0oPEysy02qDxKObWVO5vZ65qozv6zyiHldHrog 45t4+DpAbXG7dH4D6QPnLSDJu2kqTtJvgH3Ub4Z9csu/8tdoLdMmnCQLo9qGigzZqoLHto MOyUZst7DdmYxSlppN8375YQDlqhFlI= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id ffac6d22 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 25 Jul 2022 12:02:10 +0000 (UTC) Date: Mon, 25 Jul 2022 14:02:06 +0200 From: "Jason A. Donenfeld" To: Albert Huang Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Eric Biederman , Masahiro Yamada , Michal Marek , Nick Desaulniers , "Kirill A. Shutemov" , Kuppuswamy Sathyanarayanan , Michael Roth , Nathan Chancellor , Ard Biesheuvel , Joerg Roedel , Mark Rutland , Peter Zijlstra , Sean Christopherson , Kees Cook , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-kbuild@vger.kernel.org Subject: Re: [PATCH 1/4] kexec: reuse crash kernel reserved memory for normal kexec Message-ID: References: <20220725083904.56552-1-huangjie.albert@bytedance.com> <20220725083904.56552-2-huangjie.albert@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220725083904.56552-2-huangjie.albert@bytedance.com> X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,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 Albert, On Mon, Jul 25, 2022 at 04:38:53PM +0800, Albert Huang wrote: > The kexec userspace tool also needs to add parameter options(-r) that > support the use of reserved memory (see another patch for kexec) > > [...] > > - if (kexec_on_panic) { > + if (kexec_on_panic && kexec_on_reserved) { Two small questions related to this: - Why does kexec-tools need an option, or more specifically, why does userspace need to communicate about this at all? Can't the kernel just automatically use the available reserved memory in the case that's not already being used by the panic handler kernel? I'm curious about whether there are caveats that would make this occasionally undesirable, hence suggesting an option. - I don't totally understand how this works, so I might be a bit off here, but is there any chance that this could be made to co-exist with kexec_on_panic? Can a larger region just be reserved, specifically for this, rather than piggy backing on the panic handler region? > +static struct page *kimage_alloc_reserverd_control_pages(struct kimage *image, > + case KEXEC_TYPE_RESERVED_MEM: > + pages = kimage_alloc_reserverd_control_pages(image, order); Nit: reserverd -> reserved Jason