public inbox for openrisc@lists.librecores.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
Date: Fri, 18 Jan 2019 09:43:02 +0100	[thread overview]
Message-ID: <20190118084302.GA4160@osiris> (raw)
In-Reply-To: <1547646261-32535-20-git-send-email-rppt@linux.ibm.com>

On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
> 
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
> 
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + 	panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
...
> diff --git a/arch/s390/numa/toptree.c b/arch/s390/numa/toptree.c
> index 71a608c..0118c77 100644
> --- a/arch/s390/numa/toptree.c
> +++ b/arch/s390/numa/toptree.c
> @@ -31,10 +31,14 @@ struct toptree __ref *toptree_alloc(int level, int id)
>  {
>  	struct toptree *res;
> 
> -	if (slab_is_available())
> +	if (slab_is_available()) {
>  		res = kzalloc(sizeof(*res), GFP_KERNEL);
> -	else
> +	} else {
>  		res = memblock_alloc(sizeof(*res), 8);
> +		if (!res)
> +			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> +			      __func__, sizeof(*res), 8);
> +	}
>  	if (!res)
>  		return res;

Please remove this hunk, since the code _should_ be able to handle
allocation failures anyway (see end of quoted code).

Otherwise for the s390 bits:
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>


  parent reply	other threads:[~2019-01-18  8:43 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 13:44 [OpenRISC] [PATCH 00/21] Refine memblock API Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 01/21] openrisc: prefer memblock APIs returning virtual address Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 02/21] powerpc: use memblock functions " Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 03/21] memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 04/21] memblock: drop memblock_alloc_base_nid() Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 05/21] memblock: emphasize that memblock_alloc_range() returns a physical address Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 07/21] memblock: memblock_phys_alloc(): " Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 08/21] memblock: drop __memblock_alloc_base() Mike Rapoport
2019-01-16 15:15   ` Rob Herring
2019-01-16 13:44 ` [OpenRISC] [PATCH 09/21] memblock: drop memblock_alloc_base() Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 10/21] memblock: refactor internal allocation functions Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 11/21] memblock: make memblock_find_in_range_node() and choose_memblock_flags() static Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) Mike Rapoport
2019-01-18 17:53   ` Paul Burton
2019-01-16 13:44 ` [OpenRISC] [PATCH 13/21] arch: don't memset(0) memory returned by memblock_alloc() Mike Rapoport
2019-01-16 14:17   ` Geert Uytterhoeven
2019-01-16 13:44 ` [OpenRISC] [PATCH 14/21] ia64: add checks for the return value of memblock_alloc*() Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 15/21] sparc: " Mike Rapoport
2019-01-16 17:21   ` David Miller
2019-01-16 13:44 ` [OpenRISC] [PATCH 16/21] mm/percpu: " Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 17/21] init/main: " Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 18/21] swiotlb: " Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 19/21] treewide: " Mike Rapoport
2019-01-16 14:27   ` Geert Uytterhoeven
2019-01-16 15:13     ` Mike Rapoport
2019-01-16 14:32   ` [OpenRISC] [Xen-devel] " Juergen Gross
2019-01-16 15:18   ` [OpenRISC] " Rob Herring
2019-01-17  7:06   ` Guo Ren
2019-01-18  8:43   ` Heiko Carstens [this message]
2019-01-18 18:02   ` Paul Burton
2019-01-16 13:44 ` [OpenRISC] [PATCH 20/21] memblock: memblock_alloc_try_nid: don't panic Mike Rapoport
2019-01-16 13:44 ` [OpenRISC] [PATCH 21/21] memblock: drop memblock_alloc_*_nopanic() variants Mike Rapoport
2019-01-17  9:28   ` Petr Mladek
2019-01-18  8:42   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190118084302.GA4160@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=openrisc@lists.librecores.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox