Thread (66 messages) 66 messages, 8 authors, 2021-12-21

Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()

flat view

From: Borislav Petkov <bp@alien8.de>
Date: 2021-12-16 11:07:51
Also in: kexec, linux-arm-kernel, linux-doc, lkml

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help