Although it is very unlikely that the allocation during init would
fail any such failure should point to the original cause rather
than waiting for a null-pointer dereference to splat.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Problem located with experimental coccinelle script
While this will not really help much - but kzalloc failures should not
go unhandled.
Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
(with some unrelated sparse warnings about missing syscalls)
Patch is against 5.1-rc4 (localversion-next is 20190412)
arch/arm/mach-mvebu/board-v7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 0b10acd..37f8cb6 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -128,6 +128,7 @@ static void __init i2c_quirk(void)
struct property *new_compat;
new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
+ WARN_ON(!new_compat);
new_compat->name = kstrdup("compatible", GFP_KERNEL);
new_compat->length = sizeof("marvell,mv78230-a0-i2c");
--
2.1.4
The license is clearly identified as GPL V2 - so just add in the
appropriate SPDX license identifier.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Problem reported by checkpatch
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
#1: FILE: arch/arm/mach-mvebu/board-v7.c:1:
+/*
Patch is against 5.1-rc4 (localversion-next is 20190412)
arch/arm/mach-mvebu/board-v7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 28fd256..0e021c9 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Device Tree support for Armada 370 and XP platforms.
*
--
2.1.4
The return statement is unnecessary here - so drop it.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Problem reported by checkpatch
WARNING: void function return statements are not generally useful
#141: FILE: arch/arm/mach-mvebu/board-v7.c:141:
+ return;
+}
Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
(with some unrelated sparse warnings about missing syscalls)
Patch is against 5.1-rc4 (localversion-next is 20190412)
arch/arm/mach-mvebu/board-v7.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 37f8cb6..28fd256 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -137,7 +137,6 @@ static void __init i2c_quirk(void)
of_update_property(np, new_compat);
}
- return;
}
static void __init mvebu_dt_init(void)
--
2.1.4
On Sun, Apr 14, 2019 at 06:49:51AM +0200, Nicholas Mc Guire wrote:
> The license is clearly identified as GPL V2 - so just add in the
> appropriate SPDX license identifier.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
Hi Nicholas
Adding a SPDX line makes the license text redundant, so you should
remove it in the same patch as adding the SPDX line.
Andrew
On Sun, Apr 14, 2019 at 06:49:49AM +0200, Nicholas Mc Guire wrote:
> Although it is very unlikely that the allocation during init would
> fail any such failure should point to the original cause rather
> than waiting for a null-pointer dereference to splat.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
> ---
>
> Problem located with experimental coccinelle script
>
> While this will not really help much - but kzalloc failures should not
> go unhandled.
Sorry, no, not like this.
With this patch, rather than getting an oops and a stacktrace which
people can capture and email, we instead end up getting a warning
line, a stack trace, followed by an oops containing another stack
trace.
We _already_ have problems getting people to send us kernel message
debug information without editing out what they deem to be "unnecessary
verbage", like all those numbers and function names that comprise a
stack trace. We don't need yet more of that stuff, especially when it
is redundant.
So, I think throwing WARN_ON() at this case is way too excessive, and
will only have a detrimental effect on the reports we receive - and
that is extremely important.
IMHO, A better solution would be to just print a warning, rather than
causing the kernel to print several kB of needless messages.
if (!new_compat)
pr_err("new_compat allocation failure in %s()\n",
__func__);
>
> Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
> (with some unrelated sparse warnings about missing syscalls)
>
> Patch is against 5.1-rc4 (localversion-next is 20190412)
>
> arch/arm/mach-mvebu/board-v7.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 0b10acd..37f8cb6 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -128,6 +128,7 @@ static void __init i2c_quirk(void)
> struct property *new_compat;
>
> new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> + WARN_ON(!new_compat);
>
> new_compat->name = kstrdup("compatible", GFP_KERNEL);
> new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> --
> 2.1.4
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Sun, Apr 14, 2019 at 06:22:10PM +0200, Andrew Lunn wrote:
> On Sun, Apr 14, 2019 at 06:49:51AM +0200, Nicholas Mc Guire wrote:
> > The license is clearly identified as GPL V2 - so just add in the
> > appropriate SPDX license identifier.
> >
> > Signed-off-by: Nicholas Mc Guire <[email protected]>
>
> Hi Nicholas
>
> Adding a SPDX line makes the license text redundant, so you should
> remove it in the same patch as adding the SPDX line.
>
So remove that first line from this paragraph
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
reducing it to:
* This program is licensed "as is" without any warranty of any kind,
* whether express or implied.
Is that what you are proposing ?
The GPL does state that there is no warranty but using a different
wording that may not be legally equivalent.
thx!
hofrat
On Sun, Apr 14, 2019 at 06:26:02PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Apr 14, 2019 at 06:49:49AM +0200, Nicholas Mc Guire wrote:
> > Although it is very unlikely that the allocation during init would
> > fail any such failure should point to the original cause rather
> > than waiting for a null-pointer dereference to splat.
> >
> > Signed-off-by: Nicholas Mc Guire <[email protected]>
> > ---
> >
> > Problem located with experimental coccinelle script
> >
> > While this will not really help much - but kzalloc failures should not
> > go unhandled.
>
> Sorry, no, not like this.
>
ok - well I wsa not sure about it either - it just seems wrong
to leave a possible allocation failure without any response.
The issue of generating excessive outout make sense - so will fix
it up to a pr_err() and resend.
thx!
hofrat
> With this patch, rather than getting an oops and a stacktrace which
> people can capture and email, we instead end up getting a warning
> line, a stack trace, followed by an oops containing another stack
> trace.
>
> We _already_ have problems getting people to send us kernel message
> debug information without editing out what they deem to be "unnecessary
> verbage", like all those numbers and function names that comprise a
> stack trace. We don't need yet more of that stuff, especially when it
> is redundant.
>
> So, I think throwing WARN_ON() at this case is way too excessive, and
> will only have a detrimental effect on the reports we receive - and
> that is extremely important.
>
> IMHO, A better solution would be to just print a warning, rather than
> causing the kernel to print several kB of needless messages.
>
> if (!new_compat)
> pr_err("new_compat allocation failure in %s()\n",
> __func__);
>
> >
> > Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
> > (with some unrelated sparse warnings about missing syscalls)
> >
> > Patch is against 5.1-rc4 (localversion-next is 20190412)
> >
> > arch/arm/mach-mvebu/board-v7.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> > index 0b10acd..37f8cb6 100644
> > --- a/arch/arm/mach-mvebu/board-v7.c
> > +++ b/arch/arm/mach-mvebu/board-v7.c
> > @@ -128,6 +128,7 @@ static void __init i2c_quirk(void)
> > struct property *new_compat;
> >
> > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> > + WARN_ON(!new_compat);
> >
> > new_compat->name = kstrdup("compatible", GFP_KERNEL);
> > new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> > --
> > 2.1.4
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Hi Nicholas,
> The return statement is unnecessary here - so drop it.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
Applied on mvebu/arm
Thanks,
Gregory
> ---
>
> Problem reported by checkpatch
>
> WARNING: void function return statements are not generally useful
> #141: FILE: arch/arm/mach-mvebu/board-v7.c:141:
> + return;
> +}
>
> Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
> (with some unrelated sparse warnings about missing syscalls)
>
> Patch is against 5.1-rc4 (localversion-next is 20190412)
>
> arch/arm/mach-mvebu/board-v7.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 37f8cb6..28fd256 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -137,7 +137,6 @@ static void __init i2c_quirk(void)
>
> of_update_property(np, new_compat);
> }
> - return;
> }
>
> static void __init mvebu_dt_init(void)
> --
> 2.1.4
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com