[PATCH 1/1] PM / hibernate: memory_bm_find_bit -- tighten node optimisation

with the expected fallout. Ensure the zone we are scanning matches the cached zone before considering the cached node. Deep thanks go to Andrea for many, many, many hours of hacking and testing that went into cornering this bug. Reported-by: Andrea Righi Tested-by: Andrea Righi Signed-off-by: Andy Whitcroft

Re: [PATCH] checkpatch.pl: Improve WARNING on Kconfig help

On Wed, Dec 19, 2018 at 02:44:36AM -0800, Joe Perches wrote: > On Wed, 2018-12-19 at 10:35 +0200, Igor Stoppa wrote: > > The checkpatch.pl script complains when the help section of a Kconfig > > entry is too short, but it doesn't really explain what it is looking > > for. Instead, it gives a

Re: [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

l difference between the primary and compat calls. The compat call already elides the name but it also is copying into a new structure for return and this is pre-cleared, so the name will always be null for the compat case and undefined for the primary ioctl. Perhaps the below patch would be mor

Re: [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

l difference between the primary and compat calls. The compat call already elides the name but it also is copying into a new structure for return and this is pre-cleared, so the name will always be null for the compat case and undefined for the primary ioctl. Perhaps the below patch would be mor

[tip:x86/pti] x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels

Commit-ID: a14bff131108faf50cc0cf864589fd71ee216c96 Gitweb: https://git.kernel.org/tip/a14bff131108faf50cc0cf864589fd71ee216c96 Author: Andy Whitcroft <a...@canonical.com> AuthorDate: Wed, 14 Mar 2018 11:24:27 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed,

[tip:x86/pti] x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels

Commit-ID: a14bff131108faf50cc0cf864589fd71ee216c96 Gitweb: https://git.kernel.org/tip/a14bff131108faf50cc0cf864589fd71ee216c96 Author: Andy Whitcroft AuthorDate: Wed, 14 Mar 2018 11:24:27 + Committer: Ingo Molnar CommitDate: Wed, 14 Mar 2018 13:24:31 +0100 x86/speculation

[PATCH 1/1] x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32bit

In 9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") we added annotations for CALL_NOSPEC/JMP_NOSPEC on x86 64bit. We did not annotate the 32bit path. Annotate it similarly. Signed-off-by: Andy Whitcroft <a...@canonical.com> --- arch/x86/in

[PATCH 1/1] x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32bit

In 9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") we added annotations for CALL_NOSPEC/JMP_NOSPEC on x86 64bit. We did not annotate the 32bit path. Annotate it similarly. Signed-off-by: Andy Whitcroft --- arch/x86/include/asm/nospec-branch.h |

Re: checkpatch potential false positive

On Mon, Nov 06, 2017 at 03:19:14PM +1100, Tobin C. Harding wrote: > Hi, > > When parsing drivers/staging/unisys/visorbus/visorchipset.c in Greg's > staging tree checkpatch emits > > -- > visorchipset.c > -- > WARNING: char * array declaration might be better as static

Re: checkpatch potential false positive

On Mon, Nov 06, 2017 at 03:19:14PM +1100, Tobin C. Harding wrote: > Hi, > > When parsing drivers/staging/unisys/visorbus/visorchipset.c in Greg's > staging tree checkpatch emits > > -- > visorchipset.c > -- > WARNING: char * array declaration might be better as static

Re: Linux 4.12-rc6

On Tue, Jun 20, 2017 at 4:42 AM, Dave Jones wrote: > Almost shutdown, but not quite. Coincidentally, coverity just finished > the rc6 run, and barfed this up.. related ? > > *** CID 1412907: Control flow issues (DEADCODE) > /include/linux/mm.h: 2243 in vm_end_gap() >

Re: Linux 4.12-rc6

On Tue, Jun 20, 2017 at 4:42 AM, Dave Jones wrote: > Almost shutdown, but not quite. Coincidentally, coverity just finished > the rc6 run, and barfed this up.. related ? > > *** CID 1412907: Control flow issues (DEADCODE) > /include/linux/mm.h: 2243 in vm_end_gap() > 2237 > 2238 static

[Acked] [PATCH] checkpatch: Warn on embedded function names

get_quoted_string($line, $rawline) =~ > /\b$context_function\b/) { > + WARN("EMBEDDED_FUNCTION_NAME", > + "Prefer using \"%s\", __func__ to embedded > function names\n" . $herecurr); > + } > + > # check for spaces before a quoted newline > if ($rawline =~ /^.*\".*\s\\n/) { > if (WARN("QUOTED_WHITESPACE_BEFORE_NEWLINE", > -- > 2.10.0.rc2.1.g053435c > Looks sane enough to me. Acked-by: Andy Whitcroft <a...@canonical.com> -apw

[Acked] [PATCH] checkpatch: Warn on embedded function names

get_quoted_string($line, $rawline) =~ > /\b$context_function\b/) { > + WARN("EMBEDDED_FUNCTION_NAME", > + "Prefer using \"%s\", __func__ to embedded > function names\n" . $herecurr); > + } > + > # check for spaces before a quoted newline > if ($rawline =~ /^.*\".*\s\\n/) { > if (WARN("QUOTED_WHITESPACE_BEFORE_NEWLINE", > -- > 2.10.0.rc2.1.g053435c > Looks sane enough to me. Acked-by: Andy Whitcroft -apw

Re: [PATCH 1/1] checkpatch: remove false warning for commit reference

On Mon, Oct 24, 2016 at 11:39:45AM -0700, Joe Perches wrote: > On Mon, 2016-10-24 at 19:22 +0200, Heinrich Schuchardt wrote: > > On 10/23/2016 10:37 PM, Joe Perches wrote: > > > On Sun, 2016-10-23 at 09:34 +0200, Heinrich Schuchardt wrote: > > > > Checkpatch warns of an incorrect commit reference

Re: [PATCH 1/1] checkpatch: remove false warning for commit reference

On Mon, Oct 24, 2016 at 11:39:45AM -0700, Joe Perches wrote: > On Mon, 2016-10-24 at 19:22 +0200, Heinrich Schuchardt wrote: > > On 10/23/2016 10:37 PM, Joe Perches wrote: > > > On Sun, 2016-10-23 at 09:34 +0200, Heinrich Schuchardt wrote: > > > > Checkpatch warns of an incorrect commit reference

[PATCH 1/1 V2] dm raid: fix compat_features validation

>From a30fba068e41214cb0ffcb14e68722482765e0c9 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft <a...@canonical.com> Date: Tue, 11 Oct 2016 15:16:57 +0100 In ecbfb9f118bce4 ("dm raid: add raid level takeover support") a new compatible feature flag was added. Validation for th

[PATCH 1/1 V2] dm raid: fix compat_features validation

>From a30fba068e41214cb0ffcb14e68722482765e0c9 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft Date: Tue, 11 Oct 2016 15:16:57 +0100 In ecbfb9f118bce4 ("dm raid: add raid level takeover support") a new compatible feature flag was added. Validation for these compat_features was added

Re: [dm-devel] [PATCH 1/1] dm raid: fix compat_features validation

On Tue, Oct 11, 2016 at 05:04:34PM +0200, Heinz Mauelshagen wrote: > > Andy, > > good catch. > > We should rather check for V190 support only in case any > compat feature flags are actually set. > > { > + if (le32_to_cpu(sb->compat_features) && > +

Re: [dm-devel] [PATCH 1/1] dm raid: fix compat_features validation

On Tue, Oct 11, 2016 at 05:04:34PM +0200, Heinz Mauelshagen wrote: > > Andy, > > good catch. > > We should rather check for V190 support only in case any > compat feature flags are actually set. > > { > + if (le32_to_cpu(sb->compat_features) && > +

[PATCH 1/1] dm raid: fix compat_features validation

at import. Check compat_features for any valid combinations. Fixes: ecbfb9f118bce4 ("dm raid: add raid level takeover support") BugLink: http://bugs.launchpad.net/bugs/1631298 Signed-off-by: Andy Whitcroft <a...@canonical.com> --- drivers/md/dm-raid.c | 2 +- 1 file changed,

[PATCH 1/1] dm raid: fix compat_features validation

at import. Check compat_features for any valid combinations. Fixes: ecbfb9f118bce4 ("dm raid: add raid level takeover support") BugLink: http://bugs.launchpad.net/bugs/1631298 Signed-off-by: Andy Whitcroft --- drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) It

Re: [PATCH] checkpatch: Improve 'bare use of' signed/unsigned types warning

while ($line =~ > m{\b($Declare)\s*(?!char\b|short\b|int\b|long\b)\s*($Ident)?\s*[=,;\[\)\(]}g) > { > my $type = $1; > my $var = $2; > $var = "" if (!defined $var); > -- > 2.8.0.rc4.16.g56331f8 > Derp, yes. Acked-by: Andy Whitcroft <a...@canonical.com> -apw

Re: [PATCH] checkpatch: Improve 'bare use of' signed/unsigned types warning

)\s*(?!char\b|short\b|int\b|long\b)\s*($Ident)?\s*[=,;\[\)\(]}g) > { > my $type = $1; > my $var = $2; > $var = "" if (!defined $var); > -- > 2.8.0.rc4.16.g56331f8 > Derp, yes. Acked-by: Andy Whitcroft -apw

Re: [PATCH] checkpatch: Yet another commit id improvement

On Tue, Jul 19, 2016 at 03:05:56AM -0700, Joe Perches wrote: > On Tue, 2016-07-19 at 10:51 +0100, Andy Whitcroft wrote: > > On Mon, Jul 18, 2016 at 12:27:42PM -0700, Joe Perches wrote: > > > > > > Using \b isn't good enough to isolate what appears to be a > >

Re: [PATCH] checkpatch: Yet another commit id improvement

On Tue, Jul 19, 2016 at 03:05:56AM -0700, Joe Perches wrote: > On Tue, 2016-07-19 at 10:51 +0100, Andy Whitcroft wrote: > > On Mon, Jul 18, 2016 at 12:27:42PM -0700, Joe Perches wrote: > > > > > > Using \b isn't good enough to isolate what appears to be a > >

Re: [PATCH] checkpatch: Yet another commit id improvement

On Mon, Jul 18, 2016 at 12:27:42PM -0700, Joe Perches wrote: > Using \b isn't good enough to isolate what appears to be a > commit id in a commit message. > > Make sure there is a space or a quote like character after > a continuous run of hexadecimal characters that could be > a commit id. > >

Re: [PATCH] checkpatch: Yet another commit id improvement

On Mon, Jul 18, 2016 at 12:27:42PM -0700, Joe Perches wrote: > Using \b isn't good enough to isolate what appears to be a > commit id in a commit message. > > Make sure there is a space or a quote like character after > a continuous run of hexadecimal characters that could be > a commit id. > >

Re: [PATCH v3 1/2] checkpatch: add Kconfig 'default n' test

On Mon, Jun 06, 2016 at 09:43:15AM -0700, Joe Perches wrote: > On Sat, 2016-06-04 at 13:10 +0800, Yingjoe Chen wrote: > > If a Kconfig config option doesn't specify 'default', the default > > will be n. Adding 'default n' is unnecessary. > > Add a test to warn about this. > > Is it obvious that a

Re: [PATCH v3 1/2] checkpatch: add Kconfig 'default n' test

On Mon, Jun 06, 2016 at 09:43:15AM -0700, Joe Perches wrote: > On Sat, 2016-06-04 at 13:10 +0800, Yingjoe Chen wrote: > > If a Kconfig config option doesn't specify 'default', the default > > will be n. Adding 'default n' is unnecessary. > > Add a test to warn about this. > > Is it obvious that a

Re: Fwd: [PATCH] mm: add config option to select the initial overcommit mode

On Tue, May 10, 2016 at 02:00:47PM +0200, Sebastian Frias wrote: > Hi, > > Using checkpatch.pl on the forwarded patch results in: > > WARNING: please write a paragraph that describes the config symbol fully > #57: FILE: mm/Kconfig:451: > + config OVERCOMMIT_GUESS > > WARNING: please write

Re: Fwd: [PATCH] mm: add config option to select the initial overcommit mode

On Tue, May 10, 2016 at 02:00:47PM +0200, Sebastian Frias wrote: > Hi, > > Using checkpatch.pl on the forwarded patch results in: > > WARNING: please write a paragraph that describes the config symbol fully > #57: FILE: mm/Kconfig:451: > + config OVERCOMMIT_GUESS > > WARNING: please write

Re: checkpatch false positon on EXPORT_SYMBOL

On Tue, Apr 12, 2016 at 10:49:17AM -0700, Joe Perches wrote: > > On Tue, 2016-04-12 at 13:59 +0100, Andy Whitcroft wrote: > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > [] > > @@ -3000,7 +3000,7 @@ sub process { > > > >  

Re: checkpatch false positon on EXPORT_SYMBOL

On Tue, Apr 12, 2016 at 10:49:17AM -0700, Joe Perches wrote: > > On Tue, 2016-04-12 at 13:59 +0100, Andy Whitcroft wrote: > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > [] > > @@ -3000,7 +3000,7 @@ sub process { > > > >  

Re: checkpatch false positon on EXPORT_SYMBOL

be considered as spaces for the purposes of determining the next line for this purpose. The following patch appears to sort this out. A quick scan says this entire next line calculation is still only used for the EXPORT* check so this should be low risk for other tests. This works for me on your example, if you have a r

Re: checkpatch false positon on EXPORT_SYMBOL

be considered as spaces for the purposes of determining the next line for this purpose. The following patch appears to sort this out. A quick scan says this entire next line calculation is still only used for the EXPORT* check so this should be low risk for other tests. This works for me on your example, if you

Re: reinstate dm target local ioctl support

On Fri, Jan 29, 2016 at 01:57:12PM +, Alasdair G Kergon wrote: > On Thu, Jan 28, 2016 at 01:50:19PM +0000, Andy Whitcroft wrote: > > However this also removed the possibility of a dm target having target > > specific ioctls. Currently this is not used by any

Re: reinstate dm target local ioctl support

On Fri, Jan 29, 2016 at 01:57:12PM +, Alasdair G Kergon wrote: > On Thu, Jan 28, 2016 at 01:50:19PM +0000, Andy Whitcroft wrote: > > However this also removed the possibility of a dm target having target > > specific ioctls. Currently this is not used by any

reinstate dm target local ioctl support

the patch below in mainline to allow for such target local ioctls. -apw >From 3fa0480193b944dd97565364efe4df89414c250b Mon Sep 17 00:00:00 2001 From: Andy Whitcroft Date: Wed, 27 Jan 2016 16:05:32 + Subject: dm: introduce a target_ioctl op to allow target specific ioctls In e56f81e0b01e

reinstate dm target local ioctl support

rrying something like the patch below in mainline to allow for such target local ioctls. -apw >From 3fa0480193b944dd97565364efe4df89414c250b Mon Sep 17 00:00:00 2001 From: Andy Whitcroft <a...@canonical.com> Date: Wed, 27 Jan 2016 16:05:32 + Subject: dm: introduce a target_ioctl op

Re: cgroup pids controller -- WARN_ON_ONCE triggering

On Tue, Dec 08, 2015 at 10:24:28AM -0500, Tejun Heo wrote: > Hello, Andy. > > On Tue, Dec 08, 2015 at 02:58:51PM +0000, Andy Whitcroft wrote: > > Converting this to a printk I was able to obtain confirmation that we are > > indeed seeing this go negative in some case

cgroup pids controller -- WARN_ON_ONCE triggering

The commit below attempts to fix up pid controller charging: commit afcf6c8b75444382e0f9996157207ebae34a8848 Author: Tejun Heo Date: Thu Oct 15 16:41:53 2015 -0400 cgroup: add cgroup_subsys->free() method and use it to fix pids controller Since this change we are seeing system

cgroup pids controller -- WARN_ON_ONCE triggering

The commit below attempts to fix up pid controller charging: commit afcf6c8b75444382e0f9996157207ebae34a8848 Author: Tejun Heo Date: Thu Oct 15 16:41:53 2015 -0400 cgroup: add cgroup_subsys->free() method and use it to fix pids controller Since this change we are

Re: cgroup pids controller -- WARN_ON_ONCE triggering

On Tue, Dec 08, 2015 at 10:24:28AM -0500, Tejun Heo wrote: > Hello, Andy. > > On Tue, Dec 08, 2015 at 02:58:51PM +0000, Andy Whitcroft wrote: > > Converting this to a printk I was able to obtain confirmation that we are > > indeed seeing this go negative in some case

Re: [PATCH] scripts:checkpatch - correct the error message during check

On Fri, Oct 30, 2015 at 04:55:04PM +0530, shailendr...@samsung.com wrote: > From: Shailendra Verma > > Signed-off-by: Shailendra Verma > --- > scripts/checkpatch.pl | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/scripts/checkpatch.pl

Re: [PATCH] scripts:checkpatch - correct the error message during check

On Fri, Oct 30, 2015 at 04:55:04PM +0530, shailendr...@samsung.com wrote: > From: Shailendra Verma > > Signed-off-by: Shailendra Verma > --- > scripts/checkpatch.pl | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > >

Re: [PATCH 1/1] x509: only prefix strip raw serial numbers

On Tue, Sep 15, 2015 at 10:59:43AM +0100, David Howells wrote: > Andy Whitcroft wrote: > > > This leads us to truncate the id for kernel module signing keys and to > > fail to recognise our own modules: > > > > [1.572423] Loaded X.509 cert 'Build time au

Re: [PATCH 1/1] x509: only prefix strip raw serial numbers

On Tue, Sep 15, 2015 at 10:59:43AM +0100, David Howells wrote: > Andy Whitcroft <a...@canonical.com> wrote: > > > This leads us to truncate the id for kernel module signing keys and to > > fail to recognise our own modules: > > > > [1.572423] Loaded

Re: possible new false positive in checkpatch

On Tue, Sep 15, 2015 at 05:50:40PM +0300, Tal Shorer wrote: > > Yes it feels like that should be eliding them completely, and likely any > > following space as well, something like this: > > > > $s =~ s/$;+\s*//g; > > $c =~ s/$;+\s*//g; > > > Replacing the problematic lines with

Re: possible new false positive in checkpatch

On Tue, Sep 15, 2015 at 05:50:40PM +0300, Tal Shorer wrote: > > Yes it feels like that should be eliding them completely, and likely any > > following space as well, something like this: > > > > $s =~ s/$;+\s*//g; > > $c =~ s/$;+\s*//g; > > > Replacing the problematic lines with

Re: possible new false positive in checkpatch

On Sat, Sep 12, 2015 at 03:13:31PM +0300, Tal Shorer wrote: > Since my last pull from upstream (today) , I started seeing some > checkpatch warnings regarding suspect code indent I believe are false > positive. Take this code for example: > > static int foo(void) > { > while (bar()) >

[PATCH 1/1] x509: only prefix strip raw serial numbers

er. Signed-off-by: Andy Whitcroft --- crypto/asymmetric_keys/x509_public_key.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) While we are here the prefix strip seems pretty odd, only removing just one 0 byte. Is this meant to strip them all

[PATCH 1/1] x509: only prefix strip raw serial numbers

efix strip to raw serial number. Signed-off-by: Andy Whitcroft <a...@canonical.com> --- crypto/asymmetric_keys/x509_public_key.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) While we are here the prefix strip seems pretty odd, only removing just one 0 byte. Is t

Re: possible new false positive in checkpatch

On Sat, Sep 12, 2015 at 03:13:31PM +0300, Tal Shorer wrote: > Since my last pull from upstream (today) , I started seeing some > checkpatch warnings regarding suspect code indent I believe are false > positive. Take this code for example: > > static int foo(void) > { > while (bar()) >

[PATCH 1/1 V2] ipv4: off-by-one in continuation handling in /proc/net/route

quot;fib_trie: Fib walk rcu should take a tnode and key instead of a trie and a leaf") BugLink: http://bugs.launchpad.net/bugs/1483440 Acked-by: Alexander Duyck Signed-off-by: Andy Whitcroft --- net/ipv4/fib_trie.c | 2 +- 1 file changed, 1 i

[PATCH 1/1] ipv4: off-by-one in continuation handling in /proc/net/route

launchpad.net/bugs/1483440 Signed-off-by: Andy Whitcroft --- net/ipv4/fib_trie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From code inspection I belive this was introduced by the Fixes below, but I have not tested this to confirm. Fixes: 8be33e955cb9 (&quo

[PATCH 1/1] ipv4: off-by-one in continuation handling in /proc/net/route

://bugs.launchpad.net/bugs/1483440 Signed-off-by: Andy Whitcroft a...@canonical.com --- net/ipv4/fib_trie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From code inspection I belive this was introduced by the Fixes below, but I have not tested this to confirm. Fixes

[PATCH 1/1 V2] ipv4: off-by-one in continuation handling in /proc/net/route

(fib_trie: Fib walk rcu should take a tnode and key instead of a trie and a leaf) BugLink: http://bugs.launchpad.net/bugs/1483440 Acked-by: Alexander Duyck alexander.h.du...@redhat.com Signed-off-by: Andy Whitcroft a...@canonical.com --- net/ipv4/fib_trie.c | 2

[Acked] [PATCH] checkpatch: Add __pmem to $Sparse annotations

atch.pl > +++ b/scripts/checkpatch.pl > @@ -264,6 +264,7 @@ our $Sparse = qr{ > __kernel| > __force| > __iomem| > + __pmem| > __must_check| > _

Re: false positives with checkpatch

On Fri, Aug 07, 2015 at 08:37:47AM -0700, Joe Perches wrote: > On Fri, 2015-08-07 at 09:01 -0600, Ross Zwisler wrote: > > When running checkpatch.pl against my latest patch set, I hit what I think > > are > > two false positives. Here are the related lines: > > > > +static inline void

Re: false positives with checkpatch

On Fri, Aug 07, 2015 at 08:37:47AM -0700, Joe Perches wrote: On Fri, 2015-08-07 at 09:01 -0600, Ross Zwisler wrote: When running checkpatch.pl against my latest patch set, I hit what I think are two false positives. Here are the related lines: +static inline void

[Acked] [PATCH] checkpatch: Add __pmem to $Sparse annotations

+264,7 @@ our $Sparse = qr{ __kernel| __force| __iomem| + __pmem| __must_check| __init_refok| __kprobes| Acked-by: Andy Whitcroft

Re: Checkpatch: False positive

On Thu, Jul 16, 2015 at 08:58:56AM -0700, Joe Perches wrote: > On Thu, 2015-07-16 at 16:43 +0100, Andy Whitcroft wrote: > > On Thu, Jul 16, 2015 at 08:35:58AM -0700, Joe Perches wrote: > > > > #31: > > > > arc

Re: Checkpatch: False positive

On Thu, Jul 16, 2015 at 08:35:58AM -0700, Joe Perches wrote: > > #31: > > arch/x86/kernel/hpet.c | 198 > > ++--- I guess those are in the limbo land between the end of message and beginning of the patch itself. Perhaps the test should at least stop

Re: Checkpatch: False positive

On Thu, Jul 16, 2015 at 08:35:58AM -0700, Joe Perches wrote: #31: arch/x86/kernel/hpet.c | 198 ++--- I guess those are in the limbo land between the end of message and beginning of the patch itself. Perhaps the test should at least stop at the

Re: Checkpatch: False positive

On Thu, Jul 16, 2015 at 08:58:56AM -0700, Joe Perches wrote: On Thu, 2015-07-16 at 16:43 +0100, Andy Whitcroft wrote: On Thu, Jul 16, 2015 at 08:35:58AM -0700, Joe Perches wrote: #31: arch/x86/kernel/hpet.c | 198 ++--- I guess

[Acked] [PATCH V2] checkpatch: Make types found in a source file/patch local

warn "MODIFIER: $modifier ($possible) > ($line)\n" if ($dbg_possible); > - push(@modifierList, $modifier); > + push(@modifierListFile, $modifier); > } >

[Acked] [PATCH V2] checkpatch: Make types found in a source file/patch local

about right to me. Acked-by: Andy Whitcroft a...@canonical.com -apw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [PATCH] checkpatch: types found in one source file do not affect processing of others

On Mon, May 18, 2015 at 03:33:29PM +0200, Alex Dowad wrote: > checkpatch uses various cues in its input files to discover the names of > user-defined types. It then uses that information when processing expressions, > to discover more style issues. > > Unfortunately, in rare cases, this means

Re: [PATCH] checkpatch: types found in one source file do not affect processing of others

On Mon, May 18, 2015 at 03:33:29PM +0200, Alex Dowad wrote: checkpatch uses various cues in its input files to discover the names of user-defined types. It then uses that information when processing expressions, to discover more style issues. Unfortunately, in rare cases, this means that

Re: [PATCH RFC] checkpatch: flag split arithmetic operations with CHECK

On Tue, May 05, 2015 at 10:53:36AM +0200, Nicholas Mc Guire wrote: > Simple arithmetic operations should be on one line, if they can be fit, > rather than splitting at the operator. As this is not in the CodingStyle it > is limited to --strict use of checkpatch.pl and emits a CHECK only. > >

Re: [PATCH RFC] checkpatch: flag split arithmetic operations with CHECK

On Tue, May 05, 2015 at 10:53:36AM +0200, Nicholas Mc Guire wrote: Simple arithmetic operations should be on one line, if they can be fit, rather than splitting at the operator. As this is not in the CodingStyle it is limited to --strict use of checkpatch.pl and emits a CHECK only.

Re: [PATCH 1/1] pty, n_tty: continue processing input until the tty_buffer chain is flushed

On Mon, Mar 16, 2015 at 02:03:23PM -0400, Peter Hurley wrote: > I just managed to reproduce this problem with a test jig; > can you confirm that your self-tests also use >= 4096-byte read buffer > (which I think is necessary to trigger the worker race)? The read which triggers the EIO is indeed

[PATCH 1/1] pty, n_tty: continue processing input until the tty_buffer chain is flushed

nput processing on final close") BugLink: http://bugs.launchpad.net/bugs/1429756 Cc: # 3.19+ Signed-off-by: Andy Whitcroft --- drivers/tty/n_tty.c | 4 +++- drivers/tty/tty_buffer.c | 19 +++ include/linux/tty_flip.h | 2 ++ 3 files changed, 24 insertions(+), 1 deletion(-)

[PATCH 1/1] pty, n_tty: continue processing input until the tty_buffer chain is flushed

close) BugLink: http://bugs.launchpad.net/bugs/1429756 Cc: sta...@vger.kernel.org # 3.19+ Signed-off-by: Andy Whitcroft a...@canonical.com --- drivers/tty/n_tty.c | 4 +++- drivers/tty/tty_buffer.c | 19 +++ include/linux/tty_flip.h | 2 ++ 3 files changed, 24 insertions(+), 1

Re: [PATCH 1/1] pty, n_tty: continue processing input until the tty_buffer chain is flushed

On Mon, Mar 16, 2015 at 02:03:23PM -0400, Peter Hurley wrote: I just managed to reproduce this problem with a test jig; can you confirm that your self-tests also use = 4096-byte read buffer (which I think is necessary to trigger the worker race)? The read which triggers the EIO is indeed

Re: [PATCH] checkpatch: remove unneeded or ("|")

On Thu, Mar 12, 2015 at 07:13:35AM -0700, Joe Perches wrote: > On Thu, 2015-03-12 at 15:07 +0100, Christian Borntraeger wrote: > > while porting commit 89a883530fe7 ("checkpatch: ## is not a valid > > modifier") to QEMU, Peter Maydell noticed that the | at the end of > > the list is not necessary.

Re: [PATCH] checkpatch: remove unneeded or (|)

On Thu, Mar 12, 2015 at 07:13:35AM -0700, Joe Perches wrote: On Thu, 2015-03-12 at 15:07 +0100, Christian Borntraeger wrote: while porting commit 89a883530fe7 (checkpatch: ## is not a valid modifier) to QEMU, Peter Maydell noticed that the | at the end of the list is not necessary.

arm64 -- psci tell the compiler in which registers we are expecting arguments

that when you enable mcount preables (-pg) these are altered and the compilation failed. Inform the compiler of these register requirements. BugLink: http://bugs.launchpad.net/bugs/1414002 Signed-off-by: Andy Whitcroft --- arch/arm64/kernel/psci.c | 18 ++ 1 file changed, 14

arm64 -- psci tell the compiler in which registers we are expecting arguments

that when you enable mcount preables (-pg) these are altered and the compilation failed. Inform the compiler of these register requirements. BugLink: http://bugs.launchpad.net/bugs/1414002 Signed-off-by: Andy Whitcroft a...@canonical.com --- arch/arm64/kernel/psci.c | 18 ++ 1 file

Re: [PATCH V3 1/1] Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()

On Sun, Dec 14, 2014 at 11:59:19PM -0800, Jeremiah Mahler wrote: > KY Srinivasan, > > On Mon, Dec 15, 2014 at 07:00:45AM +, KY Srinivasan wrote: > > > > > > > -Original Message- > > > From: Jeremiah Mahler [mailto:jmmah...@gmail.com] > > > Sent: Wednesday, December 10, 2014 6:10 PM

Re: [PATCH V3 1/1] Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()

On Sun, Dec 14, 2014 at 11:59:19PM -0800, Jeremiah Mahler wrote: KY Srinivasan, On Mon, Dec 15, 2014 at 07:00:45AM +, KY Srinivasan wrote: -Original Message- From: Jeremiah Mahler [mailto:jmmah...@gmail.com] Sent: Wednesday, December 10, 2014 6:10 PM To: KY

Re: [PATCH] checkpatch: include text files in SPACE_BEFORE_TAB test

On Fri, Dec 05, 2014 at 09:45:37PM -0800, Frank Rowand wrote: > From: Frank Rowand > > git-am whined about a patch that I submitted for the Documentation > subtree, (https://lkml.org/lkml/2014/11/24/636) but checkpatch does > not. Make checkpatch just as whiney. > > This patch moves the

Re: [PATCH] checkpatch: include text files in SPACE_BEFORE_TAB test

On Fri, Dec 05, 2014 at 09:45:37PM -0800, Frank Rowand wrote: From: Frank Rowand frank.row...@sonymobile.com git-am whined about a patch that I submitted for the Documentation subtree, (https://lkml.org/lkml/2014/11/24/636) but checkpatch does not. Make checkpatch just as whiney. This

Re: How to cope with two incompatible overlayfs formats out in the wild

On Tue, Nov 18, 2014 at 03:28:03PM +0100, Miklos Szeredi wrote: > [CC-ing mailing lists, Al and Linus for wider exposure] > > This issue is this: Ubuntu and SUSE carry an "old" format of overlayfs > while mainline has a "new" format. The differences are: > > - whiteouts are represented

Re: How to cope with two incompatible overlayfs formats out in the wild

On Tue, Nov 18, 2014 at 03:28:03PM +0100, Miklos Szeredi wrote: [CC-ing mailing lists, Al and Linus for wider exposure] This issue is this: Ubuntu and SUSE carry an old format of overlayfs while mainline has a new format. The differences are: - whiteouts are represented differently

Re: [PATCH] checkpatch: fix use via symlink, make missing spelling file non-fatal

On Fri, Oct 24, 2014 at 02:31:50AM -0700, Joe Perches wrote: > On Fri, 2014-10-24 at 10:02 +0100, Andy Whitcroft wrote: > > On Thu, Oct 23, 2014 at 10:29:11AM -0700, Joe Perches wrote: > > > > [...] > > > my $P = $0; > > > -$P =~ s@(.*)/@@g; > > >

Re: [PATCH] checkpatch: fix use via symlink, make missing spelling file non-fatal

On Thu, Oct 23, 2014 at 10:29:11AM -0700, Joe Perches wrote: [...] > my $P = $0; > -$P =~ s@(.*)/@@g; > -my $D = $1; > +my $D = dirname(abs_path($P)); That changes the value of $P, I don't know if that is intended: my $D = dirname(abs_path($0)); or my $D = abs_path($1); perhaps to keep

Re: [PATCH] checkpatch: fix use via symlink, make missing spelling file non-fatal

On Thu, Oct 23, 2014 at 10:29:11AM -0700, Joe Perches wrote: [...] my $P = $0; -$P =~ s@(.*)/@@g; -my $D = $1; +my $D = dirname(abs_path($P)); That changes the value of $P, I don't know if that is intended: my $D = dirname(abs_path($0)); or my $D = abs_path($1); perhaps to keep $P

Re: [PATCH] checkpatch: fix use via symlink, make missing spelling file non-fatal

On Fri, Oct 24, 2014 at 02:31:50AM -0700, Joe Perches wrote: On Fri, 2014-10-24 at 10:02 +0100, Andy Whitcroft wrote: On Thu, Oct 23, 2014 at 10:29:11AM -0700, Joe Perches wrote: [...] my $P = $0; -$P =~ s@(.*)/@@g; -my $D = $1; +my $D = dirname(abs_path($P

Re: [PATCH 0/3] checkpatch: Add missing c90 types

gt; Joe Perches (3): > checkpatch: Add short int to c variable types > checkpatch: Add signed generic types > checkpatch: Add test for native c90 types in unusual order > > scripts/checkpatch.pl | 61 > --- > 1 file changed, 5

Re: [PATCH 0/3] checkpatch: Add missing c90 types

--- 1 file changed, 53 insertions(+), 8 deletions(-) Looks like a sane plan to me. Acked-by: Andy Whitcroft a...@canonical.com -apw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More

Re: [PATCH] checkpatch: Add for_each tests to indentation and brace tests

if ($line =~ /\b(?:(?:if|while|for)\s*\(|do\b)/ && $line !~ > /^.\s*#/ && $line !~ /\}\s*while\s*/) { > + if ($line =~ > /\b(?:(?:if|while|for|(?:[a-z_]+|)for_each[a-z_]+)\s*\(|do\b)/ && $line !~ > /^.\s*#/ && $line !~ /\}\s*while\s*/

Re: [PATCH] checkpatch: Add for_each tests to indentation and brace tests

, $remain_next, $off_next) = ctx_statement_block($linenr, $realcnt, 0) if (!defined $stat); With the above clarified it all seems sensible. Acked-by: Andy Whitcroft a...@canonical.com -apw -- To unsubscribe from this list: send the line

Re: [PATCH] checkpatch: Emit a warning on file add/move/delete

H", That seems like a sensible plan. Sometime we might try and work out if any entries are affected or needed. I think you are checking against the git ways of mentioning this only, don't know if there is any milage in checking the dates which also convey add/remove info via datea at the epoch. Acke

Re: [PATCH] checkpatch: Emit a warning on file add/move/delete

via datea at the epoch. Acked-by: Andy Whitcroft a...@canonical.com -apw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [PATCH] checkpatch: Enable whitespace checks for DTS files

On Mon, Jun 30, 2014 at 11:53:31AM +0200, Geert Uytterhoeven wrote: > When run on *.dtsi or *.dts files, the whitespace checks were skipped, > while they are valid for DTS files. Hence stop skipping them. > > I ran checkpatch on all in-tree DTS files, and didn't notice any error or > warning

Re: [PATCH] checkpatch: Enable whitespace checks for DTS files

On Mon, Jun 30, 2014 at 11:53:31AM +0200, Geert Uytterhoeven wrote: When run on *.dtsi or *.dts files, the whitespace checks were skipped, while they are valid for DTS files. Hence stop skipping them. I ran checkpatch on all in-tree DTS files, and didn't notice any error or warning messages

ACPI resource change triggers loss of serial ports

. For Zhang's case I wonder if this check could be tightened up to cover only the zero base, something like the (untested) patch below. -apw [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 >From e5211c68278387ef65e483bcfedd5581a79ec783 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft D

ACPI resource change triggers loss of serial ports

#1313981 [1]). These seem to represent their IO regions (presumably incorrectly) as a zero length region. Reverting the above commit restores these serial devices. Only elide zero length resources which lie at address 0. Signed-off-by: Andy Whitcroft a...@canonical.com --- drivers/acpi

  1   2   3   4   5   6   7   8   9   10   >