Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
Xi Ruoyao <[email protected]>
| Newsgroups | gmane.linux.ports.m68k,gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.acpi.devel,gmane.comp.emulators.xen.devel,gmane.linux.ports.arm.omap,gmane.linux.kernel.clk,gmane.linux.drivers.devicetree,gmane.linux.kernel.mm,gmane.linux.power-management.general |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2024-12-23 at 09:12 +0200, Mike Rapoport wrote: > On Sun, Dec 22, 2024 at 07:15:37PM +0800, Guo Weikang 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. > > > > Changelog: > > ---------- > > v1: initial version > > v2: add __memblock_alloc_or_panic support panic output caller > > v3: panic output phys_addr_t use printk's %pap > > v4: make __memblock_alloc_or_panic out-of-line, move to memblock.c > > v6: Fix CI compile error > > Links to CI: https://lore.kernel.org/oe-kbuild-all/[email protected]/ > > v6: Fix CI compile warinigs > > Links to CI: https://lore.kernel.org/oe-kbuild-all/[email protected]/ > > v7: add chagelog and adjust function declaration alignment format > > ---------- > > > > Signed-off-by: Guo Weikang <[email protected]> > > Reviewed-by: Andrew Morton <[email protected]> > > Reviewed-by: Geert Uytterhoeven <[email protected]> > > Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> > > Acked-by: Xi Ruoyao <[email protected]> > > If people commented on your patch it does not mean you should add > Reviewed-by or Acked-by tags for them. Wait for explicit tags from the > reviewers. And: - Acked-by: indicates an agreement by another developer (often a maintainer of the relevant code) that the patch is appropriate for inclusion into the kernel. I'm not a maintainer so I even don't have the right to use Acked-by :). -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University