[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] mm/memblock: Add memblock_alloc_or_panic interface
- To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- From: Weikang Guo <guoweikang.kernel@xxxxxxxxx>
- Date: Sat, 21 Dec 2024 17:59:43 +0800
- Cc: Mike Rapoport <rppt@xxxxxxxxxx>, Dennis Zhou <dennis@xxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, Christoph Lameter <cl@xxxxxxxxx>, Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>, Sam Creasey <sammy@xxxxxxxxx>, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, Huacai Chen <chenhuacai@xxxxxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Oreoluwa Babatunde <quic_obabatun@xxxxxxxxxxx>, rafael.j.wysocki@xxxxxxxxx, Palmer Dabbelt <palmer@xxxxxxxxxxxx>, Hanjun Guo <guohanjun@xxxxxxxxxx>, Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx>, Johannes Berg <johannes.berg@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxx>, Christian Brauner <brauner@xxxxxxxxxx>, KP Singh <kpsingh@xxxxxxxxxx>, Richard Henderson <richard.henderson@xxxxxxxxxx>, Matt Turner <mattst88@xxxxxxxxx>, Russell King <linux@xxxxxxxxxxxxxxx>, WANG Xuerui <kernel@xxxxxxxxxx>, Michael Ellerman <mpe@xxxxxxxxxxxxxx>, Jonas Bonn <jonas@xxxxxxxxxxxx>, Stefan Kristiansson <stefan.kristiansson@xxxxxxxxxxxxx>, Stafford Horne <shorne@xxxxxxxxx>, Helge Deller <deller@xxxxxx>, Nicholas Piggin <npiggin@xxxxxxxxx>, Christophe Leroy <christophe.leroy@xxxxxxxxxx>, Naveen N Rao <naveen@xxxxxxxxxx>, Madhavan Srinivasan <maddy@xxxxxxxxxxxxx>, Geoff Levand <geoff@xxxxxxxxxxxxx>, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, Albert Ou <aou@xxxxxxxxxxxxxxxxx>, Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx>, Alexander Potapenko <glider@xxxxxxxxxx>, Andrey Konovalov <andreyknvl@xxxxxxxxx>, Dmitry Vyukov <dvyukov@xxxxxxxxxx>, Vincenzo Frascino <vincenzo.frascino@xxxxxxx>, Heiko Carstens <hca@xxxxxxxxxxxxx>, Vasily Gorbik <gor@xxxxxxxxxxxxx>, Alexander Gordeev <agordeev@xxxxxxxxxxxxx>, Christian Borntraeger <borntraeger@xxxxxxxxxxxxx>, Sven Schnelle <svens@xxxxxxxxxxxxx>, Yoshinori Sato <ysato@xxxxxxxxxxxxxxxxxxxx>, Rich Felker <dalias@xxxxxxxx>, John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>, Andreas Larsson <andreas@xxxxxxxxxxx>, Richard Weinberger <richard@xxxxxx>, Anton Ivanov <anton.ivanov@xxxxxxxxxxxxxxxxxx>, Johannes Berg <johannes@xxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, Len Brown <lenb@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Chris Zankel <chris@xxxxxxxxxx>, Max Filippov <jcmvbkbc@xxxxxxxxx>, Tero Kristo <kristo@xxxxxxxxxx>, Michael Turquette <mturquette@xxxxxxxxxxxx>, Stephen Boyd <sboyd@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>, Saravana Kannan <saravanak@xxxxxxxxxx>, Pavel Machek <pavel@xxxxxx>, Yury Norov <yury.norov@xxxxxxxxx>, Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>, Marco Elver <elver@xxxxxxxxxx>, Al Viro <viro@xxxxxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, linux-alpha@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, loongarch@xxxxxxxxxxxxxxx, linux-m68k@xxxxxxxxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxxx, linux-openrisc@xxxxxxxxxxxxxxx, linux-parisc@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, kasan-dev@xxxxxxxxxxxxxxxx, linux-s390@xxxxxxxxxxxxxxx, linux-sh@xxxxxxxxxxxxxxx, sparclinux@xxxxxxxxxxxxxxx, linux-um@xxxxxxxxxxxxxxxxxxx, linux-acpi@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-omap@xxxxxxxxxxxxxxx, linux-clk@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, linux-pm@xxxxxxxxxxxxxxx
- Delivery-date: Sat, 21 Dec 2024 10:45:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote on Saturday, 21
December 2024 07:06:
>
> On Fri, 20 Dec 2024 17:26:38 +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.
> >
>
> Seems nice.
>
> > ...
> >
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -417,6 +417,19 @@ static __always_inline void
> > *memblock_alloc(phys_addr_t size, phys_addr_t align)
> > MEMBLOCK_ALLOC_ACCESSIBLE,
> > NUMA_NO_NODE);
> > }
> >
> > +static __always_inline void *memblock_alloc_or_panic(phys_addr_t size,
> > phys_addr_t align)
>
> We lost the printing of the function name, but it's easy to retain with
> something like
>
> #define memblock_alloc_or_panic(size, align) \
> __memblock_alloc_or_panic(size, align, __func__)
>
You're absolutely right, this was an oversight on my part. I’ll make
sure to update it with the correct function name.
> > +{
> > + void *addr = memblock_alloc(size, align);
> > +
> > + if (unlikely(!addr))
> > +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> > + panic("%s: Failed to allocate %llu bytes\n", __func__, size);
>
> Won't this always print "memblock_alloc_or_panic: Failed ..."? Not
> very useful.
>
As mentioned above.
> > +#else
> > + panic("%s: Failed to allocate %u bytes\n", __func__, size);
> > +#endif
>
> We can avoid the ifdef with printk's "%pap"?
>
I appreciate you pointing this out. I wasn’t aware of this approach,
but it’s a great idea. It definitely simplifies things, and I’ve
learned something new in the process. I'll incorporate this into the
code.
> > + return addr;
> > +}
>
|