From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Thu, 16 Dec 2021 12:07:45 +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> <9513d74c-d4c7-babd-f823-8999e195d96d@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9513d74c-d4c7-babd-f823-8999e195d96d@huawei.com> 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: "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 On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote: > The original value (1ULL << 32) is inaccurate I keep asking *why*? > and it enlarged the CRASH_ADDR_LOW upper limit. $ git grep -E "CRASH_ADDR_LOW\W" $ I have no clue what you mean here. > This is because when the memory is allocated from the low end, the > address cannot exceed CRASH_ADDR_LOW_MAX, see "if (!high)" branch. > If > the memory is allocated from the high end, 'crash_base' is greater than or > equal to (1ULL << 32), and naturally, it is greater than CRASH_ADDR_LOW_MAX. > > I think I should update the description, thanks. I think you should explain why is (1ULL << 32) wrong. It came from: eb6db83d1059 ("x86/setup: Do not reserve crashkernel high memory if low reservation failed") which simply frees the high memory portion when the low reservation fails. And the test for that is, is crash base > 4G. So that makes perfect sense to me. So your change is a NOP on 64-bit and it is a NOP on 32-bit by virtue of the _low() variant always returning 0 on 32-bit. -- 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