[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdbY-Lp7_AyqvLnQCFYkaazsmMGSHY5K85oJRNmPgM_yVA@mail.gmail.com>
Date: Mon, 5 Aug 2024 09:15:56 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: linux@...linux.org.uk, bhe@...hat.com, vgoyal@...hat.com,
dyoung@...hat.com, paul.walmsley@...ive.com, palmer@...belt.com,
aou@...s.berkeley.edu, arnd@...db.de, afd@...com, akpm@...ux-foundation.org,
rmk+kernel@...linux.org.uk, eric.devolder@...cle.com,
gregkh@...uxfoundation.org, deller@....de, javierm@...hat.com,
robh@...nel.org, thunder.leizhen@...wei.com, austindh.kim@...il.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kexec@...ts.infradead.org
Subject: Re: [PATCH 1/3] crash: Fix memory reserve dead loop bug in reserve_crashkernel_generic()
On Mon, Jul 8, 2024 at 3:30 PM Jinjie Ruan <ruanjinjie@...wei.com> wrote:
> If the platform do not support memory above 4G, such as 32 bit arch,
> and CRASH_ADDR_LOW_MAX is equal to CRASH_ADDR_HIGH_MAX, the high
> crash kernel memory reservation is meaningless and it will cause
> dead loop and system stall:
>
> -> reserve_crashkernel_generic() and high is true
> -> memblock_phys_alloc_range() fail and return 0
> -> search_end = CRASH_ADDR_LOW_MAX(same as CRASH_ADDR_HIGH_MAX)
> -> call memblock_phys_alloc_range() again and fail agin.
> -> search_end == CRASH_ADDR_HIGH_MAX satisfy again
> ......
>
> However, the current check only considers the case where
> CRASH_ADDR_HIGH_MAX is greater than CRASH_ADDR_LOW_MAX. Fix it.
>
> Fixes: 0ab97169aa05 ("crash_core: add generic function to do reservation")
> Signed-off-by: Jinjie Ruan <ruanjinjie@...wei.com>
Looks good to me:
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Yours,
Linus Walleij
Powered by blists - more mailing lists