Message-ID: <CAOm6qnnFDjyiQvUmyVA4iq5aJAO8NC=wcAvpKscvfRZKPnzkYw@mail.gmail.com>
Date: Sat, 21 Dec 2024 17:59:43 +0800
From: Weikang Guo <guoweikang.kernel@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mike Rapoport <rppt@...nel.org>, Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>, 
	Christoph Lameter <cl@...ux.com>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Sam Creasey <sammy@...my.net>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Huacai Chen <chenhuacai@...nel.org>, 
	Will Deacon <will@...nel.org>, Catalin Marinas <catalin.marinas@....com>, 
	Oreoluwa Babatunde <quic_obabatun@...cinc.com>, rafael.j.wysocki@...el.com, 
	Palmer Dabbelt <palmer@...osinc.com>, Hanjun Guo <guohanjun@...wei.com>, 
	Easwar Hariharan <eahariha@...ux.microsoft.com>, Johannes Berg <johannes.berg@...el.com>, 
	Ingo Molnar <mingo@...nel.org>, Dave Hansen <dave.hansen@...el.com>, 
	Christian Brauner <brauner@...nel.org>, KP Singh <kpsingh@...nel.org>, 
	Richard Henderson <richard.henderson@...aro.org>, Matt Turner <mattst88@...il.com>, 
	Russell King <linux@...linux.org.uk>, WANG Xuerui <kernel@...0n.name>, 
	Michael Ellerman <mpe@...erman.id.au>, Jonas Bonn <jonas@...thpole.se>, 
	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>, Stafford Horne <shorne@...il.com>, 
	Helge Deller <deller@....de>, Nicholas Piggin <npiggin@...il.com>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Geoff Levand <geoff@...radead.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Andrey Ryabinin <ryabinin.a.a@...il.com>, 
	Alexander Potapenko <glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, 
	Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, 
	Alexander Gordeev <agordeev@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>, 
	Sven Schnelle <svens@...ux.ibm.com>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, 
	Rich Felker <dalias@...c.org>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
	Andreas Larsson <andreas@...sler.com>, Richard Weinberger <richard@....at>, 
	Anton Ivanov <anton.ivanov@...bridgegreys.com>, Johannes Berg <johannes@...solutions.net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, Len Brown <lenb@...nel.org>, 
	Juergen Gross <jgross@...e.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, 
	Chris Zankel <chris@...kel.net>, Max Filippov <jcmvbkbc@...il.com>, Tero Kristo <kristo@...nel.org>, 
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, 
	Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>, Pavel Machek <pavel@....cz>, 
	Yury Norov <yury.norov@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>, 
	Marco Elver <elver@...gle.com>, Al Viro <viro@...iv.linux.org.uk>, 
	Arnd Bergmann <arnd@...db.de>, linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, loongarch@...ts.linux.dev, 
	linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org, 
	linux-openrisc@...r.kernel.org, linux-parisc@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org, 
	kasan-dev@...glegroups.com, linux-s390@...r.kernel.org, 
	linux-sh@...r.kernel.org, sparclinux@...r.kernel.org, 
	linux-um@...ts.infradead.org, linux-acpi@...r.kernel.org, 
	xen-devel@...ts.xenproject.org, linux-omap@...r.kernel.org, 
	linux-clk@...r.kernel.org, devicetree@...r.kernel.org, linux-mm@...ck.org, 
	linux-pm@...r.kernel.org
Subject: Re: [PATCH] mm/memblock: Add memblock_alloc_or_panic interface

Andrew Morton <akpm@...ux-foundation.org> wrote on Saturday, 21
December 2024 07:06:
>
> On Fri, 20 Dec 2024 17:26:38 +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.
> >
>
> 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;
> > +}
>

Powered by blists - more mailing lists