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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3F27C4332F for ; Thu, 16 Dec 2021 10:56:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236307AbhLPKz7 (ORCPT ); Thu, 16 Dec 2021 05:55:59 -0500 Received: from mail.skyhub.de ([5.9.137.197]:38056 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230379AbhLPKz6 (ORCPT ); Thu, 16 Dec 2021 05:55:58 -0500 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 0932B1EC01FC; Thu, 16 Dec 2021 11:55:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1639652153; 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=QuJ+5R6db1fiDExetCde8WgEzLmMC9GPFO7ooWuFUoc=; b=ABphLkGBVLji3yXgCnlhYPLoL/Kb44kkyTebp+C9k0SZC3hpRa920k2N8+J6ST2rMAabCA PN6F+YmOUBbI48i03dnWEAEWRo3xLHRg0JL+NRYfxJDx4yJDuKpT19d1A0jEa1sLjIIJI6 9v6iWuq2TriWabYhcqsvIRxsvM10aQQ= Date: Thu, 16 Dec 2021 11:55:55 +0100 From: Borislav Petkov To: Baoquan He Cc: Zhen Lei , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211216011040.GG3023@MiWiFi-R3L-srv> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 16, 2021 at 09:10:40AM +0800, Baoquan He wrote: > reserve_crashkernel_low() always return 0 on x86_32, so the not equivalent > transformation for x86_32 doesn't matter, I think. That is, of course, very obvious... not! Why is that function parsing crashkernel=XM, and crashkernel=X,high, then it attempts some low memory reservation too? Why isn't crashkernel=Y,low parsed there too? I guess this alludes to why: 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, before this is going anywhere, I'd like to see this function documented properly. I see Documentation/admin-guide/kdump/kdump.rst explains the crashkernel= options too so you can refer to it in the comments so that when someone looks at that code, someone can follow why it is doing what it is doing. Then, as a future work, all that parsing of crashkernel= cmdline options should be concentrated at the beginning and once it is clear what the user requests, the reservations should be done. As it is, reserve_crashkernel() is pretty unwieldy and hard to read. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette 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 F23E0C433EF for ; Thu, 16 Dec 2021 10:58:15 +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=5evCzLQ2CNvuTLlSES0NHdg4bk4f6yE6KH8yPxmo8zk=; b=OZZHNxW07iDuvw 7H8iz0t+zj1V8fmG+0U3YTdJS4iMr1g/n+MA+bwQr3VP+47mH9OjQ7drau0Yo0OGuguPvDYxmZ9EJ Ttgpr/5DDUw0tgMj4XAtAb/s7aX+BwtZIOl1xGEM9mdJvjY/HBkWw0USw6qARcOh9cgKw02IOpZbd kPxWruwxfVAPkmDiaDtWgwiXVjs45IV+As4+tinz5r2LfMxSL37r6JeWN0fMmXGatvahh1Au2LjPZ Uq9ONyUpfzP4NhU0MwuTy/vVtUcGa+C4sPr6kngLL5FWpWUgw6vEMHS6RqFDN7QXuRw6Sz/ZdtKt9 CJoSqqSN/JvfGv70KLpg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxoRD-004yem-27; Thu, 16 Dec 2021 10:56:39 +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 1mxoQb-004yLQ-1T; Thu, 16 Dec 2021 10:56:03 +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 0932B1EC01FC; Thu, 16 Dec 2021 11:55:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1639652153; 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=QuJ+5R6db1fiDExetCde8WgEzLmMC9GPFO7ooWuFUoc=; b=ABphLkGBVLji3yXgCnlhYPLoL/Kb44kkyTebp+C9k0SZC3hpRa920k2N8+J6ST2rMAabCA PN6F+YmOUBbI48i03dnWEAEWRo3xLHRg0JL+NRYfxJDx4yJDuKpT19d1A0jEa1sLjIIJI6 9v6iWuq2TriWabYhcqsvIRxsvM10aQQ= Date: Thu, 16 Dec 2021 11:55:55 +0100 From: Borislav Petkov To: Baoquan He Cc: Zhen Lei , 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211216011040.GG3023@MiWiFi-R3L-srv> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211216_025601_301892_6A2EC48F X-CRM114-Status: GOOD ( 14.25 ) 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 09:10:40AM +0800, Baoquan He wrote: > reserve_crashkernel_low() always return 0 on x86_32, so the not equivalent > transformation for x86_32 doesn't matter, I think. That is, of course, very obvious... not! Why is that function parsing crashkernel=XM, and crashkernel=X,high, then it attempts some low memory reservation too? Why isn't crashkernel=Y,low parsed there too? I guess this alludes to why: 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, before this is going anywhere, I'd like to see this function documented properly. I see Documentation/admin-guide/kdump/kdump.rst explains the crashkernel= options too so you can refer to it in the comments so that when someone looks at that code, someone can follow why it is doing what it is doing. Then, as a future work, all that parsing of crashkernel= cmdline options should be concentrated at the beginning and once it is clear what the user requests, the reservations should be done. As it is, reserve_crashkernel() is pretty unwieldy and hard to read. Thx. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Thu, 16 Dec 2021 11:55:55 +0100 From: Borislav Petkov 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211216011040.GG3023@MiWiFi-R3L-srv> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Baoquan He Cc: Zhen Lei , 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 On Thu, Dec 16, 2021 at 09:10:40AM +0800, Baoquan He wrote: > reserve_crashkernel_low() always return 0 on x86_32, so the not equivalent > transformation for x86_32 doesn't matter, I think. That is, of course, very obvious... not! Why is that function parsing crashkernel=XM, and crashkernel=X,high, then it attempts some low memory reservation too? Why isn't crashkernel=Y,low parsed there too? I guess this alludes to why: 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, before this is going anywhere, I'd like to see this function documented properly. I see Documentation/admin-guide/kdump/kdump.rst explains the crashkernel= options too so you can refer to it in the comments so that when someone looks at that code, someone can follow why it is doing what it is doing. Then, as a future work, all that parsing of crashkernel= cmdline options should be concentrated at the beginning and once it is clear what the user requests, the reservations should be done. As it is, reserve_crashkernel() is pretty unwieldy and hard to read. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec