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

[Mike Rapoport <rppt@kernel.org>]

Hi Andrew,

On Thu, Jan 02, 2025 at 03:08:35PM -0800, Andrew Morton wrote:
> 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.

I'd prefer the API to be explicit about what it does.
memblock_alloc_or_panic() is indeed longer, but it emphasizes what it does,
while memblock_alloc() that panics does not.

I also wouldn't want to duplicate all memblock_alloc* with _panic or
_nopanic versions.
 
> 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?
> 
> In fact I wonder if there is really any legitimate use of
> memblock_alloc_no_panic()?

At the very least the caller has more context and can print something more
descriptive than "failed to allocate X bytes". And I think sometimes the
boot can continue with reduced functionality. I don't have examples with
memblock_alloc() from the top of my head, but e.g. failure to reserve crash
kernel is really not a fatal error.

-- 
Sincerely yours,
Mike.