Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Nicholas Mc Guire <hofrat@osadl.org>
To:     Russell King <linux@armlinux.org.uk>
Cc:     Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        Mark Brown <broonie@kernel.org>,
        Tony Lindgren <tony@atomide.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Janusz Krzysztofik <jmkrzyszt@gmail.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Nicholas Mc Guire <hofrat@osadl.org>
Subject: [PATCH V2] ARM: imx legacy: warn on failed allocation
Date:   Tue, 16 Apr 2019 06:03:29 +0200
Message-Id: <1555387409-9018-1-git-send-email-hofrat@osadl.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Even in init the allocation can fail and thus should report by 
pr_err() so that the cause can be easily identified.

Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Link: https://lkml.org/lkml/2019/4/14/152
---

Problem located with an experimental coccinelle script

V2: Russell King <linux@armlinux.org.uk> pointed out that the use of
    WARN_ON() would result in a stack trace followed by the oops due
    to dereferencing of the NULL pointer and so make it even less
    likely that users would uncover the actual cause - so drop the 
    WARN_ON() and use a short pr_err() message that points to the 
    oops cause directly.

Note that this will trigger a checkpatch WARNING:
     "WARNING: Possible unnecessary 'out of memory' message"
but comparing the oops with an without the one-line pr_err I would argue
that it makes sense to include it (first line here is from pr_err()):
<snip>
[ 8061.514840] shared page allocation failure in hello_init()
[ 8113.563239] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 8113.563250] #PF error: [WRITE]
[ 8113.563255] PGD 8000000129993067 P4D 8000000129993067 PUD 129992067 PMD 0
[ 8113.563267] Oops: 0002 [#1] SMP PTI
[ 8113.563276] CPU: 2 PID: 2656 Comm: bash Tainted: G        W  O      5.0.0-rc3livepatchtest-next-20190123+ #4
[ 8113.563280] Hardware name: Quanta TWH/TWH, BIOS QU221 10/14/2011
[ 8113.563292] RIP: 0010:foo_store+0x3a/0x90 [hello_chardev]
...
<snip>

Patch was compile-tested with: imx_v4_v5_defconfig (implies
CONFIG_MACH_MX27ADS=y)
(with some unrelated sparse warnings about unimplemented syscalls)

Patch is against 5.1-rc4 (localversion-next is 20190415)

 arch/arm/mach-imx/mach-mx27ads.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index 6dd7f57..cba6876 100644
--- a/arch/arm/mach-imx/mach-mx27ads.c
+++ b/arch/arm/mach-imx/mach-mx27ads.c
@@ -247,6 +247,10 @@ static void __init mx27ads_regulator_init(void)
 	struct gpio_chip *vchip;
 
 	vchip = kzalloc(sizeof(*vchip), GFP_KERNEL);
+	if (!vchip)
+		pr_err("vchip allocation failure in %s()\n",
+			__func__);
+
 	vchip->owner		= THIS_MODULE;
 	vchip->label		= "LCD";
 	vchip->base		= MX27ADS_LCD_GPIO;
-- 
2.1.4