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 D9F6CC433F5 for ; Thu, 16 Dec 2021 14:50:08 +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=RMqd+XsVBuC5a9bbYFOar1sOaf4RiVFrw68mrfN4Mws=; b=h0fR+He6om6qMj EzJOO5V99jYf/UdlhKsvoITOj9ca8QK12qSHgUCPjKHWL+EcO0dAe2sA0QZZgoSRRd+1Gy3eodPW+ rMc0iAiNFPGP7NFaS8tj1ZXA7/DO9fT0AkCuh5f953kpCal4e45s+F3K9hJsgXbV14RJ+lqs2RvXF gh7Wim3MwJp8qnPM3/GWfCUSMwM6p1LWSp5kMYJYyqnHsiAnpbiQYUYWrPE/nPS8ENtvn2eEp6ff7 smJCn89rCKXsACm+XJg0QLJGAxdz1XgWIBLpqAjWcf9QgwUvZ5CGqGtnGUnD0qt6oMR59cbsjaonF sBXQ3TDK0ndYdxEsK6MQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxs3d-006E9p-FK; Thu, 16 Dec 2021 14:48:33 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxs3W-006E6H-9N; Thu, 16 Dec 2021 14:48:29 +0000 Received: from zn.tnic (dslb-088-067-202-008.088.067.pools.vodafone-ip.de [88.67.202.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 2FB6E1EC04DE; Thu, 16 Dec 2021 15:48:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1639666096; 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:in-reply-to:in-reply-to: references:references; bh=yghcZ9SCdjsqe3xvr3DH9VJQok+aWYGqWKGyGqjZksU=; b=oHYx6aYS6tIj6LoZN+GBAYyUBxsWaPwpMGtiSVdRVoeTON1rZA0a52qHjEXKVX7g//ADsi rO3av99YMS8aovAS4KRPWc+BkGVdfnBUhgOZcLNrnAGFnJ+w7jeFi2iDU7u8+Br+ggksuT 3S1KzL6GtR5B9qfhTL5iNTHFXoS142Y= Date: Thu, 16 Dec 2021 15:48:19 +0100 From: Borislav Petkov To: "Leizhen (ThunderTown)" Cc: Baoquan He , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , Vivek Goyal , Eric Biederman , kexec@lists.infradead.org, Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou Subject: Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel() Message-ID: References: <20211210065533.2023-1-thunder.leizhen@huawei.com> <20211210065533.2023-4-thunder.leizhen@huawei.com> <20211216011040.GG3023@MiWiFi-R3L-srv> <9513d74c-d4c7-babd-f823-8999e195d96d@huawei.com> <35810a61-604e-9b90-2a7f-cfca6ae042ac@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <35810a61-604e-9b90-2a7f-cfca6ae042ac@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211216_064826_517210_9DBD511C X-CRM114-Status: GOOD ( 12.24 ) X-BeenThere: linux-arm-kernel@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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Dec 16, 2021 at 08:08:30PM +0800, Leizhen (ThunderTown) wrote: > If the memory of 'crash_base' is successfully allocated at (1), because the last > parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sure that > "crash_base < CRASH_ADDR_LOW_MAX". So that, reserve_crashkernel_low() will not be > invoked at (3). That's why I said (1ULL << 32) is inaccurate and enlarge the CRASH_ADDR_LOW > upper limit. No, this is actually wrong - that check *must* be 4G. See: eb6db83d1059 ("x86/setup: Do not reserve crashkernel high memory if low reservation failed") It is even documented: crashkernel=size[KMG],low [KNL, X86-64] range under 4G. When crashkernel=X,high is passed, kernel could allocate physical memory region above 4G, that cause second kernel crash on system that require some amount of low memory, e.g. swiotlb requires at least 64M+32K low memory, also enough extra low memory is needed to make sure DMA buffers for 32-bit devices won't run out. so you need to do a low allocation for DMA *when* the reserved memory is above 4G. *NOT* above 512M. But that works due to the obscure situation, as Baoquan stated, that reserve_crashkernel_low() returns 0 on 32-bit. So all this is telling us is that that function needs serious cleanup. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel