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: <CAOm6qnmYbmUqEh_qL3SeDf2NTx2PE+nQRBe8quE1UD4uFO4jzg@mail.gmail.com>
Date: Fri, 3 Jan 2025 08:29:18 +0800
From: Weikang Guo <guoweikang.kernel@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mike Rapoport <rppt@...nel.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface

Hi, Andrew
Andrew Morton <akpm@...ux-foundation.org> wrote on Friday, 3 January 2025 07:08:
>
> 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.
>

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