[PATCH 1/1] xen-netback: include definition of csum_ipv6_magic

-off-by: Andy Whitcroft a...@canonical.com --- drivers/net/xen-netback/netback.c | 1 + 1 file changed, 1 insertion(+) Found while trying to couple latest kernels for arm64 platforms. Looks like it got missed in the transition. -apw diff --git a/drivers/net/xen-netback/netback.c b

Re: [PATCH] doc: fix generation of device-drivers

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://www.tux.org/lkml/

Re: [PATCH] - add fixpae bootparam to fix/workaround #930447

On Wed, Nov 27, 2013 at 09:41:03PM +0100, Roland wrote: This patch is meant primarly for ubuntu, as they only ship PAE enabled kernels and don`t ship non-PAE kernels anymore. So this resolves an ubuntu specific problem (as the installer disc also has PAE enabled kernel). I know it`s not

Re: [PATCH v3] checkpatch: add DT compatible string documentation checks

. Vendor prefixes are also checked for existing in vendor-prefixes.txt These should be temporary checks until we have more sophisticated binding schema checking. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Grant Likely grant.lik...@linaro.org Cc: Andy Whitcroft a...@canonical.com

Hyper-V balloon memory hotplug deadlock?

We are seeing machines lockup with what appears to be an ABBA deadlock in the memory hotplug system. These are from the 3.13.6 based Ubuntu kernels. The hv_balloon driver is adding memory using add_memory() which takes the hotplug lock, and then emits a udev event, and then attempts to lock the

[PATCH 1/1] UBUNTU: SAUCE: ubuntu: overlayfs -- ovl_path_open should not take path reference

Author: Al Viro v...@zeniv.linux.org.uk Date: Tue Jun 26 21:58:53 2012 +0400 switch dentry_open() to struct path, make it grab references itself BugLink: http://bugs.launchpad.net/bugs/1098378 Signed-off-by: Andy Whitcroft a...@canonical.com --- fs/overlayfs/super.c | 1 - 1

Re: False positive in checkpatch

On Mon, Sep 23, 2013 at 09:21:07PM -0700, Joe Perches wrote: On Mon, 2013-09-23 at 15:59 -0700, Paul E. McKenney wrote: Hello! The checkpatch.pl script complains as follows: ERROR: need consistent spacing around '*' (ctx:WxB) #57: FILE: include/linux/rcupdate.h:564: +

Re: False positive in checkpatch

5b4e22c123b3492838d12181129a8c168598dbf4 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft a...@canonical.com Date: Tue, 24 Sep 2013 16:10:46 +0100 Subject: [PATCH] checkpatch: handle miss identified binary operators which bump a close parenthesis When we hit a close parenthesis, any binary operators we have without right

Re: [PATCH] [checkpatch.pl] ctx_statement_block #if/#else/#endif fix

On Thu, May 15, 2014 at 04:43:15PM +0200, Ivo Sieben wrote: When picking up a complete statement block #if/#else/#endif prepocesor boundaries are taken into account by pushing current level type on a stack. But on an #else the level was read from stack again (without actually popping it

Re: [PATCH] [checkpatch.pl] ctx_statement_block #if/#else/#endif fix

On Wed, Jun 11, 2014 at 10:16:40AM +0100, Andy Whitcroft wrote: It doesn't seem right to remove the restore of the state. If you consider the effect of an #if/#else/#endif combination the state of the statement parser should be reset to the state at #if at the #else as the code

Re: [PATCH] [checkpatch.pl] ctx_statement_block #if/#else/#endif fix

On Wed, Jun 11, 2014 at 10:57:11AM +0100, Andy Whitcroft wrote: Signed-off-by: Andy Whitcroft a...@canonical.com With your permissions I'll add a Reported-by: etc to this patch in your name. -apw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH] x86: dma-mapping: fix GFP_ATOMIC macro usage

On Fri, Jan 17, 2014 at 8:46 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an atomic allocation, the code must test __GFP_WAIT flag

Re: [RFC] quiet checkpatch style recommendation about no spaces around bitfield :

On Mon, Mar 31, 2014 at 01:56:28PM -0700, Andrew Morton wrote: On Mon, 31 Mar 2014 08:31:38 -0700 Joe Perches j...@perches.com wrote: @@ -143,13 +143,13 @@ union cvmx_usbcx_gahbcfg { * * 1'b1: Unmask the interrupt assertion to the application. */

[PATCH 0/3] overlayfs fixes for v3.8 and later base

Following this email are three patches against overlayfs.v17 which allow it to work against v3.10-rc6 and later. With these applied overlayfs passes basic testing. overlayfs -- ovl_path_open should not take path reference Found this in testing on Ubuntu raring, testing against loopback

[PATCH 2/2] overlayfs -- follow change to do_splice_direct interface

-by: Andy Whitcroft a...@canonical.com --- fs/overlayfs/copy_up.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c index eef85e0..8e1b09f 100644 --- a/fs/overlayfs/copy_up.c +++ b/fs/overlayfs/copy_up.c @@ -90,9 +90,10 @@ static int

[PATCH 1/2] vfs: export do_splice_direct() to modules -- fix

be merged down into: vfs: export do_splice_direct() to modules.] Signed-off-by: Andy Whitcroft a...@canonical.com --- fs/internal.h | 6 -- include/linux/fs.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/internal.h b/fs/internal.h index 6dd0ffd..6c9ec69 100644

[PATCH 1/1] overlayfs -- ovl_path_open should not take path reference

Author: Al Viro v...@zeniv.linux.org.uk Date: Tue Jun 26 21:58:53 2012 +0400 switch dentry_open() to struct path, make it grab references itself BugLink: http://bugs.launchpad.net/bugs/1098378 Signed-off-by: Andy Whitcroft a...@canonical.com --- fs/overlayfs/super.c | 1 - 1

Re: [PATCH 2/2] overlayfs -- follow change to do_splice_direct interface

On Thu, Jun 27, 2013 at 06:37:45PM +0200, Miklos Szeredi wrote: Thanks for the patches, Andy. I already pushed a similar set of fixes to overlayfs.current (.v18) and to .v17 for the dentry_open() refcount fix. Bah so you did, that'll teach me for waiting for them to be tested. It is

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

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

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

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 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: 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: 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 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 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

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

[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 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] 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

[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

[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

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

[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

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

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 <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

[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()) >

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 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: 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

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: 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: 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: [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: 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 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: [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 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

[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

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: 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: [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

[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

Re: Linux 2.6.11.2

which is a patch against the 2.6.11.1 release. If consensus arrives that this patch should be against the 2.6.11 tree, it will be done that way in the future. It seems to me that we have V (delta?) and VI (delta incremental) for all the other kernel patch series. So perhaps we could have both,

Re: [PATCH 0/4] sparsemem intro patches

Andrew Morton wrote: Dave Hansen <[EMAIL PROTECTED]> wrote: The following four patches provide the last needed changes before the introduction of sparsemem. For a more complete description of what this will do, please see this patch:

Re: [PATCH] slab: cache alloc cleanups

Pekka J Enberg wrote: > [Andrew, I have been unable to find a NUMA-capable tester for this patch, > so can we please put this in to -mm for some exposure?] > > From: Pekka Enberg <[EMAIL PROTECTED]> > > This patch cleans up __cache_alloc and __cache_alloc_node functions. We no > longer need

Re: .version keeps being updated

Linus Torvalds wrote: > > On Wed, 10 Jan 2007, Linus Torvalds wrote: >> Which is why "__init" is wrong. It causes the linker to either put it at >> the end of the thing (which would break the SuSE tool). Alternatively it >> causes section mismatch problems ("init" and "const" don't work that

Re: .version keeps being updated

works? Ok, testing of this worked here across the board.All using the same configs we used for the last round of testing on this issue. The main problem machine ppc64 on SLES9 with CIFS enabled passes with this patch plus __init removed. Results on TKO. Acked-by: Andy Whitcroft <[EMA

Re: .version keeps being updated

Roman Zippel wrote: > Hi, > > On Wed, 10 Jan 2007, Linus Torvalds wrote: > >> This part: >> >> const char __init linux_banner[] = >> >> CANNOT work, because the stupid SuSE tool that look into the kernel binary >> searches for "Linux version " as the thing, and as such the "linux_banner"

Re: 2.6.19-rc6-mm2

Kay Sievers wrote: > On Tue, 2006-11-28 at 14:30 -0800, Greg KH wrote: >> On Tue, Nov 28, 2006 at 12:35:43PM +0100, Mariusz Kozlowski wrote: >>> Hello, >>> >>> When CONFIG_MODULE_UNLOAD is not set then this happens: >>> >>> CC kernel/module.o >>> kernel/module.c:852: error: `initstate'

[PATCH] make compound page destructor handling explicit

this out as explicit calls, also introduce a type for the callback function allowing them to be type checked. For each callback we pre-declare the function, causing a type error on definition rather than on use elsewhere. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> --- diff --git a/i

Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated

Mel Gorman wrote: On Mon, 4 Dec 2006, Andrew Morton wrote: , but I would of course prefer to avoid merging the anti-frag patches simply based on their stupendous size. It seems to me that lumpy-reclaim is suitable for the e1000 problem , but perhaps not for the hugetlbpage problem. I

Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated

Andrew Morton wrote: On Mon, 4 Dec 2006 20:34:29 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote: IOW: big-picture where-do-we-go-from-here stuff. Start with lumpy reclaim, I had lumpy-reclaim in my todo-queue but it seems to have gone away. I think I need a lumpy-reclaim resend, please.

Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated

Peter Zijlstra wrote: On Mon, 2006-12-04 at 11:30 -0800, Andrew Morton wrote: I'd also like to pin down the situation with lumpy-reclaim versus anti-fragmentation. No offence, but I would of course prefer to avoid merging the anti-frag patches simply based on their stupendous size. It seems

[PATCH 2/4] lumpy cleanup a missplaced comment and simplify some code

the boundary pfn calculations. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Peter Zijlstra <[EMAIL PROTECTED]> --- diff --git a/mm/vmscan.c b/mm/vmscan.c index 0f2d961..0effa3e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -606,21 +606,14 @@ keep: } /* - * zone->lru_

[PATCH 3/4] lumpy ensure we respect zone boundaries

lumpy: ensure we respect zone boundaries When scanning an aligned order N area ensure we only pull out pages in the same zone as our tag page, else we will manipulate those pages' LRU under the wrong zone lru_lock. Bad. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Peter Zi

[PATCH 0/4] Lumpy Reclaim V3

This is a repost of the lumpy reclaim patch set. This is basically unchanged from the last post, other than being rebased to 2.6.19-rc2-mm2. This has passed basic stress testing on a range of machines here. [Sorry for the delay reposting, I had a test failure and needed to confirm it was not

[PATCH 1/4] lumpy reclaim v2

Zijlstra <[EMAIL PROTECTED]> Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> --- diff --git a/fs/buffer.c b/fs/buffer.c index c953c15..2f8b073 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -374,7 +374,7 @@ static void free_more_memory(void) for_each_online_pgdat(pgdat) {

[PATCH 4/4] lumpy take the other active inactive pages in the area

and from the end of the inactive list, increasing the chances of such areas coming free together. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Peter Zijlstra <[EMAIL PROTECTED]> --- diff --git a/mm/vmscan.c b/mm/vmscan.c index 85f626b..fc23d87 100644 --- a/mm/vmscan.c +++ b

2.6.19-git13: uts banner changes break SLES9 (at least)

test.kernel.org testing seems to have shaken out a problem with the kernel banner changing, introduced by this commit: [PATCH] Fix linux banner utsname information commit a2ee8649ba6d71416712e798276bf7c40b64e6e5 We first noticed it with 2.6.19-git13 as we use this version

Re: 2.6.19-git13: uts banner changes break SLES9 (at least)

Linus Torvalds wrote: On Mon, 11 Dec 2006, Herbert Poetzl wrote: cool! should definitely work for all 'known' cases No it doesn't. Do a git grep '".*Linux version .*"' on the kernel, and see just how CRAP that "get_kernel_version" test is, and has always been. But let's hope

Re: 2.6.19-git13: uts banner changes break SLES9 (at least)

Linus Torvalds wrote: On Mon, 11 Dec 2006, Andy Whitcroft wrote: I am afraid to report that this second version also fails for me, as you point out CIFS can break us if defined. Olaf, will you admit that the SLES9 code is crap now? Andy, does just replacing the "__initdata" with &

Re: [PATCH 0/4] Lumpy Reclaim V3

Andrew Morton wrote: On Wed, 6 Dec 2006 16:59:04 + Andy Whitcroft <[EMAIL PROTECTED]> wrote: This is a repost of the lumpy reclaim patch set. more... One concern is that when the code goes to reclaim a lump and fails, we end up reclaiming a number of pages which we didn't reall

Re: [PATCH] Fix sparsemem on Cell

Dave Hansen wrote: I think the comments added say it pretty well, but I'll repeat it here. This fix is pretty similar in concept to the one that Arnd posted as a temporary workaround, but I've added a few comments explaining what the actual assumptions are, and improved it a wee little bit.

Re: OOM killer firing on 2.6.18 and later during LTP runs

Andrew Morton wrote: > On Sat, 25 Nov 2006 13:03:45 -0800 > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote: > >> On 2.6.18-rc7 and later during LTP: >> http://test.kernel.org/abat/48393/debug/console.log > > The traces are a bit confusing, but I don't actually see anything wrong > there. The

[PATCH] paravirt reorder functions to avoid unspecified behaviour

results in unspecified behavior Move memory_setup() to avoid this. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> --- diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c index 8be04da..79df6e6 100644 --- a/arch/i386/kernel/setup.c +++ b/arch/i386/kernel/setup.c @@ -494,6 +

[PATCH 0/3] Lumpy Reclaim V5

Following this email are three patches which represent the current state of the lumpy reclaim patches; collectively lumpy V5. This patch kit is against 2.6.21-rc3-mm2. This stack is split out to show the incremental changes in this version. This contains one fixup following on from Christoph

[PATCH 1/3] Lumpy Reclaim V4

ndy Whitcroft <[EMAIL PROTECTED]> Acked-by: Peter Zijlstra <[EMAIL PROTECTED]> Acked-by: Mel Gorman <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 8< Changes in lumpy V4: Andy Whitcroft: lumpy: isolate_lru_pages wants to specifically

[PATCH 2/3] lumpy: back out removal of active check in isolate_lru_pages

As pointed out by Christop Lameter it should not be possible for a page to change its active/inactive state without taking the lru_lock. Reinstate this safety net. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Mel Gorman <[EMAIL PROTECTED]> --- diff --git a/mm/v

[PATCH 3/3] lumpy: only count taken pages as scanned

. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Mel Gorman <[EMAIL PROTECTED]> --- diff --git a/mm/vmscan.c b/mm/vmscan.c index d7a0860..c3dc544 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -732,11 +732,11 @@ static unsigned long isolate_lru_pages(unsigned long

Re: [PATCH 1/3] Lumpy Reclaim V4

Dave Hansen wrote: > On Mon, 2007-03-12 at 18:23 +0000, Andy Whitcroft wrote: >> + /* The target page is in the block, ignore it. */ >> + if (unlikely(pfn == page_pfn)) >> + continue; >> +

Re: [PATCH 0/3] Lumpy Reclaim V5

Andrew Morton wrote: > On Mon, 12 Mar 2007 18:22:45 +0000 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > >> Following this email are three patches which represent the >> current state of the lumpy reclaim patches; collectively lumpy V5. > > So where do we stand

Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2

Martin Bligh wrote: > Christoph Lameter wrote: >> On Fri, 16 Mar 2007, Martin Bligh wrote: >> >>> You have to do some sort of lookup anyway, and Andy seemed to have them >>> all folded into one. >> >> What lookup would you need to do? On x86_64 even the TLB use is hidden >> by the existing 2M

2.6.21-rc3-mm2: PG_booked and PG_readahead

[applogies in advance if this has already been asked] I note that PG_booked and PG_readahead are both using bit 20 in 2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do not sound obviously non-overlapping to my mind. -apw - To unsubscribe from this list: send the line

Re: 2.6.21-rc4-mm1

Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > [All of the below is from the pre hot-fix runs. The very few results

[PATCH 1/5] Lumpy Reclaim V3

mpy reclaim V2 patch which forms the foundation. [EMAIL PROTECTED]: ia64 pfn_to_nid fixes and loop cleanup] [EMAIL PROTECTED]: static declarations for internal functions] Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> Acked-by: Peter Zijlstra <[EMAIL PROTECTED]> Signed-off-by

[PATCH 2/5] lumpy: isolate_lru_pages wants to specifically take active or inactive pages

. This is no longer an error and we should simply ignore them. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> --- diff --git a/mm/vmscan.c b/mm/vmscan.c index f15ffcb..b878d54 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -663,12 +663,13 @@ static int __isolate_lru_page(struct page *pag

<    1   2   3   4   5   6   7   8   9   10   >