[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org>
Date: Thu, 2 Jan 2025 15:08:35 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Guo Weikang <guoweikang.kernel@...il.com>
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
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.
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()?
Powered by blists - more mailing lists