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