Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface

[Weikang Guo <guoweikang.kernel@gmail.com>]

Hi, Andrew
Andrew Morton <akpm@linux-foundation.org> wrote on Friday, 3 January 2025 07:08:
>
> On Thu,  2 Jan 2025 15:25:28 +0800 Guo Weikang <guoweikang.kernel@gmail.com> wrote:
>
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immediate
> > panic is required. To simplify this behavior and reduce repetitive checks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavior.
>
> Just to be annoying...
>
> We now have many more calls to memblock_alloc_or_panic() than to
> memblock_alloc().  So perhaps memblock_alloc() should default to
> panicing and we add a new memblock_alloc_no_panic() for the exceptional
> cases.
>

A good point

> And from looking around a bit, I think many of the remaining calls to
> memblock_alloc() could be made to panic on failure anyway.  If the
> kernel cannot successfully execute memblock_alloc(small amount) at
> __init time then the kernel is hopelessly broken and there's no point
> in proceeding?

I actually did the same thing as you did, tracing back to the memblock_alloc()
caller, and indeed some of the remaining calls can also panic.There are also
very few cases where the return value is `ENOMEM`.

>
> In fact I wonder if there is really any legitimate use of
> memblock_alloc_no_panic()?

Of course, I can try to submit a new patch for discussion, but if the
default behavior
is panic, then other similar interfaces like memblock_alloc_from()
also need to be changed.

---
Guo