return value of regmap_read() should be
> checked and handled.
>
> Signed-off-by: Yizhuo
Just a few minor style issues - contentwise it look correct to me.
Reviewed-by: Nicholas Mc Guire
> ---
> drivers/iio/adc/meson_saradc.c | 28 +++-
> 1 fil
h a
> struct idr.")
The GFP_KERNEL actually was there befor this patch so not sure if this Fixes
ref is correct - I think the GFP_KERNEL was introduced in:
4e6bafdfb9f3 ("staging: bcm2835_camera: Use a mapping table for context field
of mmal_msg_header")
> Signed-off-by: Christ
generated binary (x86_64 and ppc64 binary diff).
Signed-off-by: Nicholas Mc Guire
---
Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):
on little-endian x86_64 sparse complains about:
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to
change due to limit on instruction re-ordering induced
by the additional constraint.
Signed-off-by: Nicholas Mc Guire
---
Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):
sparse was complaining about:
drivers/i2c/busses/i2c-tegra.c
On Wed, May 08, 2019 at 05:47:32PM -0400, Paul Moore wrote:
> On Wed, May 8, 2019 at 2:27 AM Nicholas Mc Guire wrote:
> > While the endiannes is being handled properly sparse was unable to verify
> > this due to type inconsistency. So introduce an additional __le32
> > respec
binary on little-endian systems - on 32bit powerpc it
does change the binary.
Signed-off-by: Nicholas Mc Guire
---
Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):
sparse complaints on different architectures fixed by this patch are
On Tue, Apr 30, 2019 at 12:58:21PM +0300, Dan Carpenter wrote:
> On Sat, Apr 27, 2019 at 05:27:25AM +0200, Nicholas Mc Guire wrote:
> > wait_for_completion_timeout() returns unsigned long (0 on timeout or
> > remaining jiffies) not int.
> >
>
> Yeah, but it's
On Tue, Apr 30, 2019 at 04:02:23AM +0100, Al Viro wrote:
> On Tue, Apr 30, 2019 at 04:22:38AM +0200, Nicholas Mc Guire wrote:
> > On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote:
> > > On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire
> > > wr
On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote:
> On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire wrote:
> >
> > V2: As requested by Sven Van Asbroeck make the
> > impact of the patch clear in the commit message.
>
> Thank you, but did you mis
On Mon, Apr 29, 2019 at 12:11:18PM +0100, Edward Cree wrote:
> On 29/04/2019 11:44, Nicholas Mc Guire wrote:
> > be16_to_cpu((__force __be16)val) should be a NOP on big-endian as well
> Yes. But it's semiotically wrong to call be16_to_cpu() on a cpu-endian
> value; if the e
While the endiannes is being handled correctly sparse was unhappy with
the missing annotation as be16_to_cpu() expects a __be16. The __force
cast to __be16 makes sparse happy but has no impact on the generated
binary.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by sparse
V2: As
introducing an additional unsigned long
variable.
Along with fixing this type inconsistency the fall-through if is
consolidated to a single if-block.
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental API conformance checking cocci script
V3: As requested by Sven Van Asbroeck
wait_for_completion_timeout() returns unsigned long (0 on timeout or
remaining jiffies) not int - so rather than introducing an additional
variable simply wrap the completion into an if().
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental API conformance checking cocci
While the endiannes is being handled correctly sparse was unhappy with
the missing annotation as be16_to_cpu() expects a __be16.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by sparse
As far as I understand sparse here the __force is actually the only
solution possible to inform
On Sat, Apr 27, 2019 at 03:20:54AM -0400, Sven Van Asbroeck wrote:
> On Sat, Apr 27, 2019 at 3:01 AM Nicholas Mc Guire wrote:
> > > > (some unrelated sparse warnings (cast to restricted __be16))
> > >
> > > That sounds interesting too. Could you provide more deta
weit_for_completion_interruptible returns in (0 on completion and
-ERESTARTSYS on interruption) - so use an int not long for API conformance
and simplify the logic here a bit: need not check explicitly for == 0 as
this is either -ERESTARTSYS or 0.
Signed-off-by: Nicholas Mc Guire
---
Problem
On Sat, Apr 27, 2019 at 02:17:42AM -0400, Sven Van Asbroeck wrote:
> Hello Nicholas, thank you for your contribution, I really appreciate it !
> See inline comments below.
>
> On Sat, Apr 27, 2019 at 12:32 AM Nicholas Mc Guire wrote:
> >
> > wait_for_completion_timeout()
wait_for_completion_timeout() returns unsigned long (0 on timeout or
remaining jiffies) not int. thus there is no negative case to check for
here.
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental API conformance checking cocci script
Q: It is not really clear if the
wait_for_completion_timeout() returns unsigned long (0 on timeout or
remaining jiffies) not int.
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental API conformance checking cocci script
Patch was compile-tested with: x86_64_defconfig + GREYBUS=m
Patch is against 5.1-rc6
weit_for_completion_interruptible returns in (0 on completion and
-ERESTARTSYS on interruption) - so use an int not long for API conformance
and simplify the logic here a bit: need not check explicitly for == 0 as
this is either -ERESTARTSYS or 0.
Signed-off-by: Nicholas Mc Guire
---
Problem
then
will fail with -EINVAL.
Signed-off-by: Nicholas Mc Guire
Reported-by: kbuild test robot
---
Problem located with experimental coccinelle script
V2: The != VCHIQ_SUCCES went unnoticed not clear how I did that as
building drivers/staging/vc04_services/vchiq.o seemed to have succeeded
then
will fail with -EINVAL.
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental coccinelle script
Patch was compile-tested with: bcm2835_defconfig (implies BCM2835_VCHIQ=m)
(with sparse warning:
CHECK drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
On Wed, Apr 17, 2019 at 02:07:44PM +0200, Gregory CLEMENT wrote:
> Hi Nicholas,
>
> Nicholas Mc Guire writes:
>
> > On Tue, Apr 16, 2019 at 03:39:57PM +0200, Andrew Lunn wrote:
> >> On Tue, Apr 16, 2019 at 05:56:31AM +0200, Nicholas Mc Guire wrote:
> >>
On Tue, Apr 16, 2019 at 03:39:57PM +0200, Andrew Lunn wrote:
> On Tue, Apr 16, 2019 at 05:56:31AM +0200, Nicholas Mc Guire wrote:
>
> > Note that this will trigger a checkpatch WARNING
> > "WARNING: Possible unnecessary 'out of memory' message"
> > bu
get_maintainer.pl only returns linux-kernel@vger.kernel.org for the
drivers/soc/ux500/ files - fix it by adding drivers/soc/ux500/ entry
Signed-off-by: Nicholas Mc Guire
Suggested-by: Ulf Hansson
---
Patch is aginst 5.1-rc4 (localversion-next is 20190415)
MAINTAINERS | 1 +
1 file changed, 1
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
Link: https://lkml.org/lkml/2019/4/14/152
---
Problem located with an experimental coccinelle script
V2: Russell King pointed out that the use
Although it is very unlikely that the allocation during init would
fail any such failure should point to the original cause to allow
easier understanding of the ensuing null-pointer dereference splat.
Signed-off-by: Nicholas Mc Guire
---
Problem located with experimental coccinelle script
V2
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
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:
The license is clearly identified as GPL V2 - so just add in the
appropriate SPDX license identifier.
Signed-off-by: Nicholas Mc Guire
---
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
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
---
Problem located with experimental coccinelle script
While this will not
The return statement is unnecessary here - so drop it.
Signed-off-by: Nicholas Mc Guire
---
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
On Sat, Apr 13, 2019 at 11:11:05AM -0300, Fabio Estevam wrote:
> On Sat, Apr 13, 2019 at 4:30 AM Nicholas Mc Guire wrote:
> >
> > The header clearly identifies this code as GPL V2 or later - so pop
> > in the SPDX license identifier.
> >
> > Signed-off-by: Nichola
Even in init the allocation can fail and thus should at least warn so
that the cause can be identified.
Signed-off-by: Nicholas Mc Guire
---
Problem located with an experimental coccinelle script
Note sure if there is a better solution as this is early in the boot
process so not that could be
Sorry for the noise - I accidentally sent out a set of old patches
along with this cleanups set. Only the ARM: imx legacy: should
have goon out.
While preparing a proposed fix for a missing check on zmalloc a few
other checkpatch warnings poped up - this little set fixes those
warnings. There is o
The header clearly identifies this code as GPL V2 or later - so pop
in the SPDX license identifier.
Signed-off-by: Nicholas Mc Guire
---
arch/arm/mach-imx/mach-mx27ads.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index
Checkpatch suggests to place a parenthesis around this complex macro.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by checkpatch
I'm actually not sure this really is improving readability but by
default checkpatch gets it right so...
Patch was compile-tested with: imx_v4_v5_defc
provide the proper type for unsigned int.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by checkpatch
Patch was compile-tested with: imx_v4_v5_defconfig (implies
CONFIG_MACH_MX27ADS=y)
Patch is against 5.1-rc4 (localversion-next is 20190412)
arch/arm/mach-imx/mach-mx27ads.c | 4
check seems mandated here.
Signed-off-by: Nicholas Mc Guire
0002 Fixes: commit 06cc5c1d4d73 ("ARM: hisi: enable hix5hd2 SoC")
---
Problem found by an experimental coccinelle script
Patch was compile tested with: hisi_defconfig (implies CONFIG_SMP=y)
Patch is against 4.18-rc3 (localve
imx_set_aips is assuming that the address returned from of_iomap is
valid which it probably is in the normal case - as the call site
is void error propagation is not possible but never the less at least
a WARN_ON() seems warranted here.
Signed-off-by: Nicholas Mc Guire
Fixes: commit
The call to of_iomap() is unchecked but scu_enable(), which the returned
address is passed on to, assumes a valid mapping. If the mapping is
invalid this could probably lead to undefined system state so at least
a warning should be issued.
Signed-off-by: Nicholas Mc Guire
Fixes: commit
Even in init the allocation can fail and thus should at least warn so
that the cause can be identified.
Signed-off-by: Nicholas Mc Guire
---
Problem located with an experimental coccinelle script
Note sure if there is a better solution as this is early in the boot
process so not that could be
Relying on an unchecked of_iomap() which can return NULL is problematic
here, an explicit check seems mandatory. Also the call to
of_find_compatible_node() returns a device node with refcount incremented
therefor an explicit of_node_put() is needed here.
Signed-off-by: Nicholas Mc Guire
Fixes
If the device node is not found or the of_iomap() failed, calling
scu_enable would not be safe and could lead to an undefined system
state. So warn in both failure paths before returning.
Signed-off-by: Nicholas Mc Guire
Link: http://lkml.org/lkml/2018/7/16/219
Fixes: commit 65ebcc115889 (&quo
Checkpatch suggests to place a parenthesis around this complex macro.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by checkpatch
I'm actually not sure this really is improving readability but by
default checkpatch gets it right so...
Patch was compile-tested with: imx_v4_v5_defc
The header clearly identifies this code as GPL V2 or later - so pop
in the SPDX license identifier.
Signed-off-by: Nicholas Mc Guire
---
arch/arm/mach-imx/mach-mx27ads.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index
provide the proper type for unsigned int.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by checkpatch
Patch was compile-tested with: imx_v4_v5_defconfig (implies
CONFIG_MACH_MX27ADS=y)
Patch is against 5.1-rc4 (localversion-next is 20190412)
arch/arm/mach-imx/mach-mx27ads.c | 4
of_find_compatible_node() returns a pointer with refcount incremented
so both in the error path as well as after usage in soc_info_populate()
respectively actually b8500_read_soc_id() an explicit of_node_put is
needed to release backupram.
Signed-off-by: Nicholas Mc Guire
Fixes: commit
While preparing a proposed fix for a missing check on zmalloc a few
other checkpatch warnings poped up - this little set fixes those
warnings. There is one remaining checkpatch warning but that looks
like a false-positive to me:
ERROR: Use of __initconst requires a separate use of const
#171: FILE
kmalloc return for bigrxbuf_virtual was not being checked - in case
of failure set status, cleanup bigtxbuf_virtual and baile out.
Signed-off-by: Nicholas Mc Guire
Fixes: c7c8c78fdf6e ("ARM: 5667/3: U300 SSP/SPI board setup and test")
---
Issue found with experimental coccinelle s
The call to of_find_compatible_node() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage. (see drivers/of/base.c:of_find_compatible_node())
Signed-off-by: Nicholas Mc Guire
---
Problem located with an experimental coccinelle script
This patch set addresses two issues in arch/arm/mach-hisi/hotplug.c
1) The hisi hotplug functions were using a few unchecked
of_iomap() while at the same time the system relied on
those mappings. Checks for !NULL were inserted.
2) Further some mandatory of_node_put() were missing and have
of_iomap() can return NULL which seems critical here and thus should be
explicitly flagged so that the cause of system halting can be understood.
As of_find_compatible_node() is returning a device node with refcount
incremented it must be explicitly decremented here.
Signed-off-by: Nicholas Mc
On Thu, Apr 11, 2019 at 06:12:49AM -0700, Joe Perches wrote:
> On Thu, 2019-04-11 at 14:59 +0200, Nicholas Mc Guire wrote:
> > On Thu, Apr 11, 2019 at 04:51:25AM -0700, Joe Perches wrote:
> > > On Thu, 2019-04-11 at 04:56 +0200, Nicholas Mc Guire wrote:
> > > > On W
On Thu, Apr 11, 2019 at 04:51:25AM -0700, Joe Perches wrote:
> On Thu, 2019-04-11 at 04:56 +0200, Nicholas Mc Guire wrote:
> > On Wed, Apr 10, 2019 at 03:53:51PM -0700, Stephen Boyd wrote:
> > > Quoting Nicholas Mc Guire (2019-04-06 20:13:24)
> > > > Providing a range
hrtimer optimization.
Signed-off-by: Nicholas Mc Guire
---
Problem located with an experimental coccinelle script
V2: As clarified by Ulf Hansson the delays
here are typically in the millisecond range - so as proposed
replace the factor 2 by a 25
On Thu, Apr 11, 2019 at 11:36:45AM +0200, Ulf Hansson wrote:
> On Sun, 7 Apr 2019 at 05:13, Nicholas Mc Guire wrote:
> >
> > Providing a range for usleep_range() allows the hrtimer subsystem to
> > coalesce timers - the delay is runtime configurable so a factor 2
> > is
On Wed, Apr 10, 2019 at 03:53:51PM -0700, Stephen Boyd wrote:
> Quoting Nicholas Mc Guire (2019-04-06 20:13:24)
> > Providing a range for usleep_range() allows the hrtimer subsystem to
> > coalesce timers - the delay is runtime configurable so a factor 2
> > is taken
Providing a range for usleep_range() allows the hrtimer subsystem to
coalesce timers - the delay is runtime configurable so a factor 2
is taken to provide the range.
Signed-off-by: Nicholas Mc Guire
---
Problem located with an experimental coccinelle script
Providing a range for usleep_range() allows the hrtimer subsystem to
coalesce timers - as this delay has no upper limit anyway (interrupts
or context switch is possible) it should not hurt to extend this
from 2 to 2-4 milliseconds.
Signed-off-by: Nicholas Mc Guire
---
Problem located with an
Pop in the SPDX tag as the license is clearly indicated
as GPL V2 or later this should also be indicated with a SPDX license
identifier tag.
Signed-off-by: Nicholas Mc Guire
---
chackpatch.pl was warning:
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
Patch was compile
Pop in the SPDX tag as the license is clearly indicated
as GPL V2 or later this should also be indicated with a SPDX license
identifier tag.
Signed-off-by: Nicholas Mc Guire
---
chackpatch.pl was warning:
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
Patch was compile
r8822be: check kzalloc return or bail")
> Link: https://github.com/ClangBuiltLinux/linux/issues/375
> Signed-off-by: Nathan Chancellor
Reviewed-by: Nicholas Mc Guire
> ---
> drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 2 +-
> 1 file changed, 1 i
The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL
so check the psd_set->data after allocation and if allocation failed
return HALMAC_CMD_PROCESS_ERROR.
Signed-off-by: Nicholas Mc Guire
Fixes: 938a0447f094 ("staging: r8822be: Add code for halmac sub-drive")
---
to mode 0666 will fail respectively revert to 0664.
Signed-off-by: Nicholas Mc Guire
---
V2: the descriptions were not too helpful as noted by
Greg Kroah-Hartman
so lets see if V2 is any better...
Documentation/filesystems/sysfs.txt | 21 +
1 file changed, 21
0666 will fail.
Signed-off-by: Nicholas Mc Guire
---
Note quite sure if this is the right place to place the note on mode 0666
but it should be somewhere as any attempt to set 0666 will be reverted
to 0664.
Documentation/filesystems/sysfs.txt | 16
1 file changed, 16 insertions
On Fri, Jan 25, 2019 at 04:44:18PM +0100, Jiri Kosina wrote:
> On Thu, 24 Jan 2019, Nicholas Mc Guire wrote:
>
> > Sparse reported warnings about non-static symbols. For the variables
> > a simple static attribute is fine - for the functions referenced by
> > livepatch
On Wed, Jan 23, 2019 at 12:45:11PM -0600, Steve Wise wrote:
>
>
> On 1/23/2019 12:30 PM, Jason Gunthorpe wrote:
> > On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote:
> >> The kmalloc is called with | __GFP_NOFAIL so there is no point in
> >&g
attribute to the shared statically declared functions.
Signed-off-by: Nicholas Mc Guire
Suggested-by: Joe Lawrence
Acked-by: Miroslav Benes
Link:
https://lore.kernel.org/lkml/1544965657-26804-1-git-send-email-hof...@osadl.org/
---
V2: not all static functions shared need to carry the __noclone
On Wed, Jan 23, 2019 at 03:30:57PM +0100, Miroslav Benes wrote:
> Hi,
>
> On Wed, 23 Jan 2019, Nicholas Mc Guire wrote:
>
> > Sparse reported warnings about non-static symbols. For the variables
> > a simple static attribute is fine - for the functions referenced by
&g
kzalloc(sizeof(int)) is called for an int object but then
passed into klp_shadow_alloc() using the size of the pointer.
This probably is not a problem as it will fit - but it should
be cleaned (after all this is reference code).
Signed-off-by: Nicholas Mc Guire
---
Reported by coccicheck
attribute to the shared statically declared functions.
Signed-off-by: Nicholas Mc Guire
Suggested-by: Joe Lawrence
Link: https://lkml.org/lkml/2018/12/13/827
---
V2: not all static functions shared need to carry the __noclone
attribute only those that need to be resolved at runtime by
On Tue, Jan 22, 2019 at 11:30:30AM -0500, Joe Lawrence wrote:
> On 12/18/18 10:18 AM, Joe Lawrence wrote:
> >On 12/18/2018 03:49 AM, Miroslav Benes wrote:
> >>On Mon, 17 Dec 2018, Joe Lawrence wrote:
> >>
> >>>I'm just being picky about its documentation and how we should note its
> >>>usage in the
Checking of kmalloc() seems to have been committed - as
cx23885_dvb_register() is checking for != 0 return, returning
-ENOMEM should be fine here. While at it address the coccicheck
suggestion to move to kmemdup rather than using kmalloc+memcpy.
Signed-off-by: Nicholas Mc Guire
Fixes
__GFP_NOFAIL should be only in exceptional
cases as I understand it and alloc_srq_queue() is called in quite
a few places)
In either way it would need fixing.
Signed-off-by: Nicholas Mc Guire
Fixes: 6a0b6174d35a ("rdma/cxgb4: Add support for kernel mode SRQ's")
---
Found during code re
On Thu, Jan 10, 2019 at 01:43:01PM -0600, Li Yang wrote:
> On Sat, Dec 22, 2018 at 2:02 AM Nicholas Mc Guire wrote:
> >
> > On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote:
> > > On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote:
> > > &g
On Mon, Dec 24, 2018 at 10:38:04AM +0100, Nicholas Mc Guire wrote:
> On Mon, Dec 24, 2018 at 09:10:56AM +0100, Michal Hocko wrote:
> > On Sat 22-12-18 09:04:21, Nicholas Mc Guire wrote:
> > > On Fri, Dec 21, 2018 at 01:58:39PM -0800, David Rientjes wrote:
> > > > On
On Mon, Dec 24, 2018 at 09:10:56AM +0100, Michal Hocko wrote:
> On Sat 22-12-18 09:04:21, Nicholas Mc Guire wrote:
> > On Fri, Dec 21, 2018 at 01:58:39PM -0800, David Rientjes wrote:
> > > On Thu, 20 Dec 2018, Nicholas Mc Guire wrote:
> > >
> > > > d
On Fri, Dec 21, 2018 at 01:58:39PM -0800, David Rientjes wrote:
> On Thu, 20 Dec 2018, Nicholas Mc Guire wrote:
>
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 871e41c..1c118d7 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1258,7 +125
On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote:
> On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote:
> > devm_kstrdup() may return NULL if internal allocation failed, but
> > as machine is from the device tree, and thus RO, devm_kstrdup_const()
> > ca
seems to have been a check for NULL return. So if this is
expected to never fail should it not be using | __GFP_NOFAIL here ?
Or put differently - what is the rational for GFP_NOWAIT to be safe here ?
Signed-off-by: Nicholas Mc Guire
Fixes 43ebdac42f16 ("vmalloc: use kzalloc() instead of alloc_bo
kzalloc can return NULL so a check is needed. Further move the
allocation checks before the remaining initialization and bail
out without initialization if allocation failed returning NULL.
Signed-off-by: Joe Perches
Signed-off-by: Nicholas Mc Guire
Fixes: 3d4ef9a15343 ("smb3: fix redu
On Tue, Dec 18, 2018 at 09:33:58AM -0800, Joe Perches wrote:
> On Tue, 2018-12-18 at 17:27 +0100, Nicholas Mc Guire wrote:
> > kzalloc can return NULL so a check is needed. While there is a
> > check for ret_buf there is no check for the allocation of
> > ret_buf->crfid.
ems appropriate.
As the kzalloc() is the only thing here that can fail it is
moved to the beginning so as not to initialize other resources
on failure of kzalloc.
Signed-off-by: Nicholas Mc Guire
Fixes: 3d4ef9a15343 ("smb3: fix redundant opens on root")
---
Problem located with an
On Mon, Dec 17, 2018 at 10:44:36AM -0500, Joe Lawrence wrote:
> On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > Hi,
> >
> > I'm sorry for being late to the party.
> >
> > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> >
> >> Spars
declared functions.
Signed-off-by: Nicholas Mc Guire
Suggested-by: Joe Lawrence
Link: https://lkml.org/lkml/2018/12/13/827
---
V2: not all static functions shared need to carry the __noclone
attribute only those that need to be resolved at runtime by
livepatch - so drop the unnecessary
On Fri, Dec 14, 2018 at 04:34:23PM -0500, Joe Lawrence wrote:
> On 12/14/2018 11:56 AM, Nicholas Mc Guire wrote:
> > Sparse reported warnings about non-static symbols. For the variables a
> > simple static attribute is fine - for those symbols referenced by
> > livepatch vi
used
for the statically declared functions.
Signed-off-by: Nicholas Mc Guire
Link: https://lkml.org/lkml/2018/12/13/827
---
sparse reported the following warnings:
CHECK samples/livepatch/livepatch-shadow-fix1.c
samples/livepatch/livepatch-shadow-fix1.c:74:14: warning: symbol
: Nicholas Mc Guire
Fixes: 439e7271dc2b ("livepatch: introduce shadow variable API")
---
Problem located with an experimental coccinelle script
Patch was compile tested with: x86_64_defconfig + FTRACE=y
FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y,
SAMPLE_LIVEPATCH=y
Patch is ag
On Thu, Dec 13, 2018 at 11:39:25AM -0500, Joe Lawrence wrote:
> On 12/13/2018 10:39 AM, Nicholas Mc Guire wrote:
> > On Thu, Dec 13, 2018 at 09:14:18AM -0500, Joe Lawrence wrote:
> >> On 12/13/2018 09:05 AM, Nicholas Mc Guire wrote:
> >>> kzalloc() return sho
On Thu, Dec 13, 2018 at 09:14:18AM -0500, Joe Lawrence wrote:
> On 12/13/2018 09:05 AM, Nicholas Mc Guire wrote:
> > kzalloc() return should be checked. On dummy_alloc() failing
> > in kzalloc() NULL should be returned.
> >
> > Signed-off-by: Nicholas Mc Guire
&
kzalloc() return should be checked. On dummy_alloc() failing
in kzalloc() NULL should be returned.
Signed-off-by: Nicholas Mc Guire
---
Problem was located with an experimental coccinelle script
V2: returning NULL is ok but not without cleanup - thanks to
Petr Mladek for catching this
kzalloc() return should always be checked - notably in example code
where this may be seen as reference. On failure of allocation
livepatch_fix1_dummy_alloc() should return NULL.
Signed-off-by: Nicholas Mc Guire
---
Problem was located with an experimental coccinelle script
V2: ...and since it
On Thu, Dec 13, 2018 at 01:31:39PM +0100, Petr Mladek wrote:
> On Thu 2018-12-13 12:09:49, Nicholas Mc Guire wrote:
> > kzalloc() return should always be checked - notably in example code
> > where this may be seen as reference. On failure of allocation
> > livepatch_fix1
kzalloc() return should be checked. On dummy_alloc() failing
in kzalloc() NULL should be returned.
Signed-off-by: Nicholas Mc Guire
---
Problem was located with an experimental coccinelle script
Patch was compile tested with: x86_64_defconfig + FTRACE=y
FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP
kzalloc() return should always be checked - notably in example code
where this may be seen as reference. On failure of allocation
livepatch_fix1_dummy_alloc() should return NULL.
Signed-off-by: Nicholas Mc Guire
---
Problem was located with an experimental coccinelle script
Patch was compile
.
Signed-off-by: Nicholas Mc Guire
Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
Reviewed-by: Geert Uytterhoeven
---
Problem was located with an experimental coccinelle script
V2: drop the dev_err() messages as requested by Geert Uytterhoeven
- thanks !
Patch w
devm_kstrdup() may return NULL if internal allocation failed, but
as machine is from the device tree, and thus RO, devm_kstrdup_const()
can be used here, which will only copy the reference.
Signed-off-by: Nicholas Mc Guire
Fixes: a6fc3b698130 ("soc: fsl: add GUTS driver for QorIQ plat
On Tue, Dec 04, 2018 at 02:11:33PM +, Peter Rosin wrote:
> Ho hmm. Had another look at this patch, or rather, the context of the
> patch so not really related, but...
>
> On 2018-12-01 11:01, Nicholas Mc Guire wrote:
> > devm_kstrdup() may return NULL if internal allocatio
On Tue, Dec 04, 2018 at 01:49:11PM +, Peter Rosin wrote:
> On 2018-12-04 13:13, Nicholas Mc Guire wrote:
> > On Tue, Dec 04, 2018 at 11:16:59AM +, Peter Rosin wrote:
> >> Hi!
> >>
> >> This patch looks like a good idea. However, a nitpick below.
> &
1 - 100 of 925 matches
Mail list logo
