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