linux-kernel - Re: [PATCH v8] mm/memblock: Add memblock_alloc_or

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z4DzQ60u0iNEwdjZ@kernel.org>
Date: Fri, 10 Jan 2025 12:15:31 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Guo Weikang <guoweikang.kernel@...il.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface

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@...il.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.