linux-next: manual merge of the akpm tree with the tip tree

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/process_64.c between commit 90e240142bd3 ("x86: Merge the
x86_32 and x86_64 cpu_idle() functions") from the tip tree and commit
54d16004d978 ("x86: use this_cpu_xxx to replace percpu_xxx funcs") from
the akpm tree.

The former moved the code to another file, so I did this change from the
latter (in enter_idle) to arch/x86/kernel/process.c.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/x86/xen/smp_pv.c

between commit:

  66a07b44e765 ("x86/entry: Switch XEN/PV hypercall entry to IDTENTRY")

from the tip tree and patch:

  "mm: introduce include/linux/pgtable.h"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index ae4d0f283df3..679d7e87a68b 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -26,7 +26,7 @@
 
 #include <asm/paravirt.h>
 #include <asm/desc.h>
-#include <asm/pgtable.h>
+#include <linux/pgtable.h>
 #include <asm/idtentry.h>
 #include <asm/cpu.h>
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  mm/swap.c

between commit:

  b01b21419999 ("mm/swap: Use local_lock for protection")

from the tip tree and patch:

  "mm/swap.c: annotate data races for lru_rotate_pvecs"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --git a/mm/swap.c b/mm/swap.c
index a8442ed0bb16..936d6b545217 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -620,7 +620,8 @@ void lru_add_drain_cpu(int cpu)
 		__pagevec_lru_add(pvec);
 
 	pvec = &per_cpu(lru_rotate.pvec, cpu);
-	if (pagevec_count(pvec)) {
+	/* Disabling interrupts below acts as a compiler barrier. */
+	if (data_race(pagevec_count(pvec))) {
 		unsigned long flags;
 
 		/* No harm done if a racing interrupt already did this */
@@ -781,7 +782,7 @@ void lru_add_drain_all(void)
 		struct work_struct *work = &per_cpu(lru_add_drain_work, cpu);
 
 		if (pagevec_count(&per_cpu(lru_pvecs.lru_add, cpu)) ||
-		    pagevec_count(&per_cpu(lru_rotate.pvec, cpu)) ||
+		    data_race(pagevec_count(&per_cpu(lru_rotate.pvec, cpu))) ||
 		    pagevec_count(&per_cpu(lru_pvecs.lru_deactivate_file, cpu)) ||
 		    pagevec_count(&per_cpu(lru_pvecs.lru_deactivate, cpu)) ||
 		    pagevec_count(&per_cpu(lru_pvecs.lru_lazyfree, cpu)) ||

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/x86/platform/efi/efi_64.c

between commit:

  1f299fad1e31 ("efi/x86: Limit EFI old memory map to SGI UV machines")

from the tip tree and patch:

  "x86: mm+efi: convert ptdump_walk_pgd_level() to take a mm_struct"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/platform/efi/efi_64.c
index e2accfe636bd,515eab388b56..000000000000
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@@ -470,10 -606,10 +470,10 @@@ void __init efi_runtime_update_mappings
  void __init efi_dump_pagetable(void)
  {
  #ifdef CONFIG_EFI_PGT_DUMP
 -	if (efi_enabled(EFI_OLD_MEMMAP))
 +	if (efi_have_uv1_memmap())
- 		ptdump_walk_pgd_level(NULL, swapper_pg_dir);
+ 		ptdump_walk_pgd_level(NULL, &init_mm);
  	else
- 		ptdump_walk_pgd_level(NULL, efi_mm.pgd);
+ 		ptdump_walk_pgd_level(NULL, &efi_mm);
  #endif
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  scripts/atomic/check-atomics.sh

between commit:

  4ad119545d78 ("locking/atomics: Check atomic headers with sha1sum")

from the tip tree and patch:

  "scripts/atomic/check-atomics.sh: don't assume that scripts are executable"

from the akpm tree.

I fixed it up (this latter patch is now needed against the new
scripts/atomic/gen-atomics.sh instead) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Wed, 13 Feb 2019 17:49:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   scripts/atomic/check-atomics.sh
> 
> between commit:
> 
>   4ad119545d78 ("locking/atomics: Check atomic headers with sha1sum")
> 
> from the tip tree and patch:
> 
>   "scripts/atomic/check-atomics.sh: don't assume that scripts are executable"
> 
> from the akpm tree.
> 
> I fixed it up (this latter patch is now needed against the new
> scripts/atomic/gen-atomics.sh instead) and can carry the fix as
> necessary.

Thanks.  I don't know why I've been carrying that fix for so long :(
Shall resend.

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/x86/platform/intel-mid/device_libs/platform_bt.c

between commit:

  9d0513d82f1a ("x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"")

from the tip tree and patch:

  "arch/x86/platform/intel-mid/device_libs/platform_bt.c: fix const confusion"

from the akpm tree.

I fixed it up (I dropped the akpm tree patch) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andy Shevchenko]

On Tue, 2018-01-09 at 16:02 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/x86/platform/intel-mid/device_libs/platform_bt.c
> 
> between commit:
> 
>   9d0513d82f1a ("x86/platform/intel-mid: Revert "Make 'bt_sfi_data'
> const"")
> 
> from the tip tree and patch:
> 
>   "arch/x86/platform/intel-mid/device_libs/platform_bt.c: fix const
> confusion"
> 
> from the akpm tree.
> 
> I fixed it up (I dropped the akpm tree patch)

Yes, that is exactly what needs to be done.
Thanks!

Andrew, can you drop that patch from your quilt?

>  and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but
> any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to
> consider
> cooperating with the maintainer of the conflicting tree to minimise
> any
> particularly complex conflicts.
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

linux-next: manual merge of the akpm tree with the tip tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Hi Andrew,

Today's linux-next merge of (well, import of) the akpm tree got a
conflict in:

  include/linux/sched/mm.h

between commit:

  68e21be2916b35 ("sched/headers: Move task->mm handling methods to <linux/sched/mm.h>")

from the tip tree and commit:

  d3a5cfa169959b ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")

from the akpm tree.

I don't feel confident fixing this up, I'm trying to figure out how to
drop one of the commits but this script isn't the clearest in it's
intent.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On Mon, Oct 16, 2017 at 07:48:10PM +0100, Mark Brown wrote:

> I don't feel confident fixing this up, I'm trying to figure out how to
> drop one of the commits but this script isn't the clearest in it's
> intent.

OK, I might've figured it out or I might've made a terrible mess.
Either way it seems to pass a basic smoke test.

Later on in the merge process I also found additional conflicts,
including extensive conflicts which look like reformatting issues in
btrfs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in:

  arch/x86/mm/init.c
  arch/x86/mm/ioremap.c

between commit:

  66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h")

from the tip tree and patch:

  "x86: use set_memory.h header"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/mm/init.c
index 2193799ca800,adbfb095bade..000000000000
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@@ -5,8 -5,8 +5,8 @@@
  #include <linux/memblock.h>
  #include <linux/bootmem.h>	/* for max_low_pfn */
  
- #include <asm/cacheflush.h>
+ #include <asm/set_memory.h>
 -#include <asm/e820.h>
 +#include <asm/e820/api.h>
  #include <asm/init.h>
  #include <asm/page.h>
  #include <asm/page_types.h>
diff --cc arch/x86/mm/ioremap.c
index e4f7b25df18e,1924c4ab8be5..000000000000
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@@ -14,8 -13,8 +14,8 @@@
  #include <linux/vmalloc.h>
  #include <linux/mmiotrace.h>
  
- #include <asm/cacheflush.h>
+ #include <asm/set_memory.h>
 -#include <asm/e820.h>
 +#include <asm/e820/api.h>
  #include <asm/fixmap.h>
  #include <asm/pgtable.h>
  #include <asm/tlbflush.h>

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  kernel/sched/fair.c

between commit:

  0ccb977f4c80 ("sched/fair: Explicitly generate __update_load_avg() instances")

from the tip tree and patch:

   "kernel/sched/fair.c: uninline __update_load_avg()"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/sched/fair.c
index 359dbc05a3b4,28a2bd8bfb67..000000000000
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@@ -2929,11 -2848,14 +2929,11 @@@ accumulate_sum(u64 delta, int cpu, stru
   *   load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
   *            = u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
   */
- static __always_inline int
+ static int
 -__update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 +___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
  		  unsigned long weight, int running, struct cfs_rq *cfs_rq)
  {
 -	u64 delta, scaled_delta, periods;
 -	u32 contrib;
 -	unsigned int delta_w, scaled_delta_w, decayed = 0;
 -	unsigned long scale_freq, scale_cpu;
 +	u64 delta;
  
  	delta = now - sa->last_update_time;
  	/*

Re: linux-next: manual merge of the akpm tree with the tip tree

[Peter Zijlstra]

On Fri, Mar 31, 2017 at 04:44:51PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   kernel/sched/fair.c
> 
> between commit:
> 
>   0ccb977f4c80 ("sched/fair: Explicitly generate __update_load_avg() instances")
> 
> from the tip tree and patch:
> 
>    "kernel/sched/fair.c: uninline __update_load_avg()"
> 
> from the akpm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Argh!

Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andi Kleen]

> Argh!
> 
> Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().

Why dropping the second?  Do you have something better?

On the first there were no 0day regressions, so at least basic performance
checking has been done.

-Andi

Re: linux-next: manual merge of the akpm tree with the tip tree

[Peter Zijlstra]

On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > Argh!
> > 
> > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
> 
> Why dropping the second?  Do you have something better?

The try_cmpxchg() patches save about half the text, and do not have the
out-of-line penalty as shown here:

   https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net

> On the first there were no 0day regressions, so at least basic performance
> checking has been done.

The first is superseded by much better patches in the scheduler tree.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andi Kleen]

On Fri, Mar 31, 2017 at 04:45:46PM +0200, Peter Zijlstra wrote:
> On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > > Argh!
> > > 
> > > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
> > 
> > Why dropping the second?  Do you have something better?
> 
> The try_cmpxchg() patches save about half the text, and do not have the
> out-of-line penalty as shown here:
> 
>    https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net

Where is the source for the benchmark?

Based on the description it sounds like it's testing atomic_inc(), which my patches
don't change.

BTW testing such things in tight loops is bad practice. If you run
them back to back the CPU pipeline has to do much more serialization,
which is usually not realistic and drastically overestimates
the overhead.

A better practice is to run some real workload. If you want to see
cycle counts you can look at LBR cycles, or PT cycles from sampling or tracing.

> > On the first there were no 0day regressions, so at least basic performance
> > checking has been done.
> 
> The first is superseded by much better patches in the scheduler tree.

Which patches exactly?  The new patches shrink the text too?

-Andi

Re: linux-next: manual merge of the akpm tree with the tip tree

[Peter Zijlstra]

On Fri, Mar 31, 2017 at 09:02:42AM -0700, Andi Kleen wrote:
> On Fri, Mar 31, 2017 at 04:45:46PM +0200, Peter Zijlstra wrote:
> > On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > > > Argh!
> > > > 
> > > > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
> > > 
> > > Why dropping the second?  Do you have something better?
> > 
> > The try_cmpxchg() patches save about half the text, and do not have the
> > out-of-line penalty as shown here:
> > 
> >    https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net
> 
> Where is the source for the benchmark?

In that email; heck marc.info even provides a downloadable link, you
don't even have to go find it in your local lkml archives.

> Based on the description it sounds like it's testing atomic_inc(),
> which my patches don't change.

Yes, reading is hard.

It tests:

 lock incl

vs

 call refcount_inc

vs

 $inlined refcount_inc

And refcount_inc() is more complex than add_unless().

> BTW testing such things in tight loops is bad practice. If you run
> them back to back the CPU pipeline has to do much more serialization,
> which is usually not realistic and drastically overestimates
> the overhead.
> 
> A better practice is to run some real workload. If you want to see
> cycle counts you can look at LBR cycles, or PT cycles from sampling or tracing.

Hey, at least I did benchmark it. You just waved your hands and are
causing extra work for other people.

> > > On the first there were no 0day regressions, so at least basic performance
> > > checking has been done.
> > 
> > The first is superseded by much better patches in the scheduler tree.
> 
> Which patches exactly?  The new patches shrink the text too?

Try your local google foo; or look at the patch that conflicted, its
that one and the next.

In the end it comes down to -mm carrying patches against trees that are
maintained elsewhere without acks from said maintainers. I don't feel
bad about causing conflicts.

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/x86/include/asm/atomic.h

between commit:

  e6790e4b5d5e ("locking/atomic/x86: Use atomic_try_cmpxchg()")

from the tip tree and patch:

  "x86/atomic: move __arch_atomic_add_unless out of line"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --git a/arch/x86/lib/atomic.c b/arch/x86/lib/atomic.c
index 88c8372109f8..4b8f6b842be9 100644
--- a/arch/x86/lib/atomic.c
+++ b/arch/x86/lib/atomic.c
@@ -12,16 +12,11 @@
  */
 int __arch_atomic_add_unless(atomic_t *v, int a, int u)
 {
-	int c, old;
-	c = arch_atomic_read(v);
-	for (;;) {
-		if (unlikely(c == (u)))
+	int c = arch_atomic_read(v);
+	do {
+		if (unlikely(c == u))
 			break;
-		old = arch_atomic_cmpxchg((v), c, c + (a));
-		if (likely(old == c))
-			break;
-		c = old;
-	}
+	} while (!atomic_try_cmpxchg(v, &c, c + a));
 	return c;
 }
 EXPORT_SYMBOL(__arch_atomic_add_unless);

Re: linux-next: manual merge of the akpm tree with the tip tree

[Peter Zijlstra]

On Fri, Mar 24, 2017 at 04:40:26PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/x86/include/asm/atomic.h
> 
> between commit:
> 
>   e6790e4b5d5e ("locking/atomic/x86: Use atomic_try_cmpxchg()")
> 
> from the tip tree and patch:
> 
>   "x86/atomic: move __arch_atomic_add_unless out of line"
> 
> from the akpm tree.

Urgh, that patch shouldn't be in mm in any case. Also with the
try_cmpxchg() change, the text gain is reduced (about half).

Furthermore, micro-benchmarks show that turning cmpxchg loops like this
into a function makes them more expensive; see:

  https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  drivers/gpu/drm/omapdrm/omap_gem.c

between commit:

  f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")

from the tip tree and patch:

  "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"

from the akpm tree.

These a basically the same patch, so I dropped the one from the akpm tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   drivers/gpu/drm/omapdrm/omap_gem.c
> 
> between commit:
> 
>   f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
> 
> from the tip tree and patch:
> 
>   "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"
> 
> from the akpm tree.
> 
> These a basically the same patch, so I dropped the one from the akpm tree.

Andrew, what's your preference for merging it? I can drop it too.

Thanks,

	Ingo

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Thu, 10 Mar 2016 09:00:25 +0100 Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm tree got a conflict in:
> > 
> >   drivers/gpu/drm/omapdrm/omap_gem.c
> > 
> > between commit:
> > 
> >   f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
> > 
> > from the tip tree and patch:
> > 
> >   "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"
> > 
> > from the akpm tree.
> > 
> > These a basically the same patch, so I dropped the one from the akpm tree.
> 
> Andrew, what's your preference for merging it? I can drop it too.
> 

I've dropped the -mm copy.  That's what I do in 99.99% of cases.  Which
means that if the version which was in someone else's -next tree later
gets lost (happens sometimes), the patch is lost altogether.

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/x86/platform/efi/efi.c

between commit:

  1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")

from the tip tree and commit:

  e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/platform/efi/efi.c
index e80826e6f3a9,122584ec27ef..000000000000
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@@ -232,14 -241,14 +241,14 @@@ void __init efi_print_memmap(void
  	for (p = memmap.map, i = 0;
  	     p < memmap.map_end;
  	     p += memmap.desc_size, i++) {
- 		char buf[64];
+ 		efi_memory_desc_t *md = p;
+ 		u64 size = md->num_pages << EFI_PAGE_SHIFT;
+ 		char buf[64], buf3[32];
  
- 		md = p;
- 		pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n",
+ 		pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%s)\n",
  			i, efi_md_typeattr_format(buf, sizeof(buf), md),
- 			md->phys_addr,
- 			md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1,
- 			(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
 -			md->phys_addr, md->phys_addr + size,
++			md->phys_addr, md->phys_addr + size -1,
+ 			efi_size_format(buf3, sizeof(buf3), size));
  	}
  #endif  /*  EFI_DEBUG  */
  }

Re: linux-next: manual merge of the akpm tree with the tip tree

[Matt Fleming]

On Tue, 09 Feb, at 03:50:24PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/x86/platform/efi/efi.c
> 
> between commit:
> 
>   1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
> 
> from the tip tree and commit:
> 
>   e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")
> 
> from the akpm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I think Andrew agreed to drop this patch from his tree,

  https://lkml.kernel.org/r/20160122151100.GA3747@codeblueprint.co.uk

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Tue, 09 Feb, at 03:50:24PM, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm tree got a conflict in:
> > 
> >   arch/x86/platform/efi/efi.c
> > 
> > between commit:
> > 
> >   1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
> > 
> > from the tip tree and commit:
> > 
> >   e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")
> > 
> > from the akpm tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> I think Andrew agreed to drop this patch from his tree,
> 
>   https://lkml.kernel.org/r/20160122151100.GA3747@codeblueprint.co.uk

... and I tried to follow up on the original submission to still preserve this 
change, as it's no doubt useful to produce easier to read bootup messages.

Thanks,

	Ingo

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/entry/entry_64_compat.S between commit 7a5a9824c18f
("x86/asm/entry/32: Remove unnecessary optimization in stub32_clone")
from the tip tree and commit cfb3fabb5c2c ("x86: opt into
HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit") from the akpm tree.

I fixed it up (they had the same effect on this file, so I just used
the tip tree version) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/common.c between commit 6b51311c9765
("x86/asm/entry/64: Use a define for an invalid segment selector") from
the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
fix warning") from the akpm tree.

I fixed it up (I just used the tip tree version) and can carry the fix
as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> fix warning") from the akpm tree.

So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute 
ago:

 triton:~/linux.trees.git> git log f28c11e4b695 --
 fatal: bad revision 'f28c11e4b695'
 triton:~/linux.trees.git> git describe
 next-20150408

How am I supposed to fetch and interpret such sha1's?

Thanks,

	Ingo

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Wed, 8 Apr 2015 17:13:51 +0200 Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm tree got a conflict in
> > arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> > ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> > the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> > fix warning") from the akpm tree.
> 
> So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute 
> ago:
> 
>  triton:~/linux.trees.git> git log f28c11e4b695 --
>  fatal: bad revision 'f28c11e4b695'
>  triton:~/linux.trees.git> git describe
>  next-20150408
> 
> How am I supposed to fetch and interpret such sha1's?

Stephen didn't include the -mm patch so I guess that ID never was
included in -next.

For -mm patches the place to bookmark is
http://ozlabs.org/~akpm/mmotm/broken-out/.

This:
http://ozlabs.org/~akpm/mmotm/broken-out/arch-x86-kernel-cpu-commonc-fix-warning.patch

It sounds like the warning has now been fixed.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

Hi Ingo,

On Wed, 8 Apr 2015 17:13:51 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Today's linux-next merge of the akpm tree got a conflict in
> > arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> > ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> > the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> > fix warning") from the akpm tree.
> 
> So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute 
> ago:
> 
>  triton:~/linux.trees.git> git log f28c11e4b695 --
>  fatal: bad revision 'f28c11e4b695'
>  triton:~/linux.trees.git> git describe
>  next-20150408
> 
> How am I supposed to fetch and interpret such sha1's?

Sorry, this was a special case.  This was a patch in the part of
Andrew's series that gets rebased on top of the rest of linux-next each
day (as that part has dependencies on other things in linux-next).  In
this case, the resolution was to drop the patch entirely as it had
become unnecessary.

This was it:

From: Andrew Morton <akpm@linux-foundation.org>
Subject: arch/x86/kernel/cpu/common.c: fix warning

x86_64 allnoconfig:

arch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1225: warning: right shift count >= width of type

Fixes: a76c7f4604937bc ("x86/asm/entry/64: Fold syscall32_cpu_init() into its sole user")
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/x86/kernel/cpu/common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN arch/x86/kernel/cpu/common.c~arch-x86-kernel-cpu-commonc-fix-warning arch/x86/kernel/cpu/common.c
--- a/arch/x86/kernel/cpu/common.c~arch-x86-kernel-cpu-commonc-fix-warning
+++ a/arch/x86/kernel/cpu/common.c
@@ -1222,7 +1222,7 @@ void syscall_init(void)
 	wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)ia32_sysenter_target);
 #else
 	wrmsrl(MSR_CSTAR, ignore_sysret);
-	wrmsrl_safe(MSR_IA32_SYSENTER_CS, 0);
+	wrmsrl_safe(MSR_IA32_SYSENTER_CS, 0ULL);
 	wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL);
 	wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL);
 #endif
_

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/Kbuild between commit 073d8224d299 ("arch: Remove
stub cputime.h headers") from the tip tree and commit "x86: use generic
early_ioremap" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/Kbuild
index 4acddc43ee0c,c98cd05d1cdf..000000000000
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@@ -5,5 -5,5 +5,6 @@@ genhdr-y += unistd_64.
  genhdr-y += unistd_x32.h
  
  generic-y += clkdev.h
 +generic-y += cputime.h
+ generic-y += early_ioremap.h
  generic-y += mcs_spinlock.h

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/softirq.c between commit c795eb55e740 ("sched/preempt, locking:
Rework local_bh_{dis,en}able()") from the tip tree and commit  ("softirq:
use const char * const for softirq_to_name, whitespace neatening") from
the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/softirq.c
index e60c41d0087a,527520152ad2..000000000000
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@@ -138,10 -149,9 +138,9 @@@ void _local_bh_enable(void
  	WARN_ON_ONCE(in_irq());
  	__local_bh_enable(SOFTIRQ_DISABLE_OFFSET);
  }
- 
  EXPORT_SYMBOL(_local_bh_enable);
  
 -static inline void _local_bh_enable_ip(unsigned long ip)
 +void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
  {
  	WARN_ON_ONCE(in_irq() || irqs_disabled());
  #ifdef CONFIG_TRACE_IRQFLAGS
@@@ -155,8 -165,8 +154,8 @@@
  	/*
  	 * Keep preemption disabled until we are done with
  	 * softirq processing:
-  	 */
+ 	 */
 -	preempt_count_sub(SOFTIRQ_DISABLE_OFFSET - 1);
 +	preempt_count_sub(cnt - 1);
  
  	if (unlikely(!in_interrupt() && local_softirq_pending())) {
  		/*

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/posix-cpu-timers.c between commits a85721601ad2 ("posix_timers:
Kick full dynticks CPUs when a posix cpu timer is armed") and
555347f6c080 ("posix_timers: New API to prevent from stopping the tick
when timers are running") from the tip tree and commit "posix_cpu_timer:
consolidate expiry time type" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/posix-cpu-timers.c
index 84d5cb3,e5286b5..0000000
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@@ -155,22 -106,7 +108,22 @@@ static void bump_cpu_timer(struct k_iti
  	}
  }
  
 +/**
 + * task_cputime_zero - Check a task_cputime struct for all zero fields.
 + *
 + * @cputime:	The struct to compare.
 + *
 + * Checks @cputime to see if all fields are zero.  Returns true if all fields
 + * are zero, false if any field is nonzero.
 + */
 +static inline int task_cputime_zero(const struct task_cputime *cputime)
 +{
 +	if (!cputime->utime && !cputime->stime && !cputime->sum_exec_runtime)
 +		return 1;
 +	return 0;
 +}
 +
- static inline cputime_t prof_ticks(struct task_struct *p)
+ static inline unsigned long long prof_ticks(struct task_struct *p)
  {
  	cputime_t utime, stime;
  
@@@ -1408,8 -1312,8 +1354,8 @@@ void set_process_cpu_timer(struct task_
  		}
  
  		if (!*newval)
 -			return;
 +			goto out;
- 		*newval += now.cpu;
+ 		*newval += now;
  	}
  
  	/*

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
include/linux/sched.h between commit cf4aebc292fa ("sched: Move sched.h
sysctl bits into separate header") from the tip tree and commit "aio:
don't include aio.h in sched.h" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/sched.h
index fe38049,f0e3a11..0000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -326,8 -339,23 +326,6 @@@ extern int mutex_spin_on_owner(struct m
  struct nsproxy;
  struct user_namespace;
  
- #include <linux/aio.h>
- 
 -/*
 - * Default maximum number of active map areas, this limits the number of vmas
 - * per mm struct. Users can overwrite this number by sysctl but there is a
 - * problem.
 - *
 - * When a program's coredump is generated as ELF format, a section is created
 - * per a vma. In ELF, the number of sections is represented in unsigned short.
 - * This means the number of sections should be smaller than 65535 at coredump.
 - * Because the kernel adds some informative sections to a image of program at
 - * generating coredump, we need some margin. The number of extra sections is
 - * 1-3 now and depends on arch. We use "5" as safe margin, here.
 - */
 -#define MAPCOUNT_ELF_CORE_MARGIN	(5)
 -#define DEFAULT_MAX_MAP_COUNT	(USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN)
 -
 -extern int sysctl_max_map_count;
 -
  #ifdef CONFIG_MMU
  extern void arch_pick_mmap_layout(struct mm_struct *mm);
  extern unsigned long

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/timeconst.pl between commit 63a3f603413f ("timeconst.pl: Eliminate
Perl warning") from the tip tree and commit "timeconst.pl: remove
deprecated defined(@array)" from the akpm tree.

These both fix the same problem, I arbitrarily chose the akpm tree version.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[H. Peter Anvin]

On 02/13/2013 08:25 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> kernel/timeconst.pl between commit 63a3f603413f ("timeconst.pl: Eliminate
> Perl warning") from the tip tree and commit "timeconst.pl: remove
> deprecated defined(@array)" from the akpm tree.
>
> These both fix the same problem, I arbitrarily chose the akpm tree version.
>

I should try to resurrect the bc version (which doesn't need the canning 
junk, bc being the POSIX tool for arbitrary-precision arithmetic.) 
There was an error on one of akpm's machines long ago which confused the 
bcrap out of us, because bc hadn't changed, but recently someone pointed 
to a bug in *make* (relating to pipes) from around that era which would 
have explained (a) the failure, and (b) why it only hit one box even 
though bc was the exact same version.
	
	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/mm/numa.c between commit 07f4207a305c ("x86-32, mm: Remove
reference to alloc_remap()") from the tip tree and commit "x86: get
pg_data_t's memory from other node" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/mm/numa.c
index a8483df,245a4ba..0000000
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -209,22 -213,27 +209,21 @@@ static void __init setup_node_data(int 
  	       nid, start, end - 1);
  
  	/*
 -	 * Allocate node data.  Try remap allocator first, node-local
 -	 * memory and then any node.  Never allocate in DMA zone.
 +	 * Allocate node data.  Try node-local memory and then any node.
 +	 * Never allocate in DMA zone.
  	 */
- 	nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
 -	nd = alloc_remap(nid, nd_size);
 -	if (nd) {
 -		nd_pa = __phys_addr_nodebug(nd);
 -		remapped = true;
 -	} else {
 -		nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
 -		if (!nd_pa) {
 -			pr_err("Cannot find %zu bytes in any node\n", nd_size);
 -			return;
 -		}
 -		nd = __va(nd_pa);
++	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
 +	if (!nd_pa) {
- 		pr_err("Cannot find %zu bytes in node %d\n",
- 		       nd_size, nid);
++		pr_err("Cannot find %zu bytes in any node\n", nd_size);
 +		return;
  	}
 +	nd = __va(nd_pa);
  
  	/* report and initialize */
 -	printk(KERN_INFO "  NODE_DATA [mem %#010Lx-%#010Lx]%s\n",
 -	       nd_pa, nd_pa + nd_size - 1, remapped ? " (remapped)" : "");
 +	printk(KERN_INFO "  NODE_DATA [mem %#010Lx-%#010Lx]\n",
 +	       nd_pa, nd_pa + nd_size - 1);
  	tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
 -	if (!remapped && tnid != nid)
 +	if (tnid != nid)
  		printk(KERN_INFO "    NODE_DATA(%d) on node %d\n", nid, tnid);
  
  	node_data[nid] = nd;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in kernel/smp.c between commit c7b798525b50 ("smp: Fix SMP function call empty cpu mask race") from the tip tree and commit "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" from the akpm tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/smp.c
index 93e576e,51a81b0..0000000
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@@ -30,10 -21,8 +21,9 @@@ enum 
  };
  
  struct call_function_data {
- 	struct call_single_data	csd;
- 	atomic_t		refs;
+ 	struct call_single_data	__percpu *csd;
  	cpumask_var_t		cpumask;
 +	cpumask_var_t		cpumask_ipi;
  };
  
  static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
@@@ -482,85 -397,39 +398,45 @@@ void smp_call_function_many(const struc
  	}
  
  	data = &__get_cpu_var(cfd_data);
- 	csd_lock(&data->csd);
- 
- 	/* This BUG_ON verifies our reuse assertions and can be removed */
- 	BUG_ON(atomic_read(&data->refs) || !cpumask_empty(data->cpumask));
- 
- 	/*
- 	 * The global call function queue list add and delete are protected
- 	 * by a lock, but the list is traversed without any lock, relying
- 	 * on the rcu list add and delete to allow safe concurrent traversal.
- 	 * We reuse the call function data without waiting for any grace
- 	 * period after some other cpu removes it from the global queue.
- 	 * This means a cpu might find our data block as it is being
- 	 * filled out.
- 	 *
- 	 * We hold off the interrupt handler on the other cpu by
- 	 * ordering our writes to the cpu mask vs our setting of the
- 	 * refs counter.  We assert only the cpu owning the data block
- 	 * will set a bit in cpumask, and each bit will only be cleared
- 	 * by the subject cpu.  Each cpu must first find its bit is
- 	 * set and then check that refs is set indicating the element is
- 	 * ready to be processed, otherwise it must skip the entry.
- 	 *
- 	 * On the previous iteration refs was set to 0 by another cpu.
- 	 * To avoid the use of transitivity, set the counter to 0 here
- 	 * so the wmb will pair with the rmb in the interrupt handler.
- 	 */
- 	atomic_set(&data->refs, 0);	/* convert 3rd to 1st party write */
  
- 	data->csd.func = func;
- 	data->csd.info = info;
- 
- 	/* Ensure 0 refs is visible before mask.  Also orders func and info */
- 	smp_wmb();
- 
- 	/* We rely on the "and" being processed before the store */
  	cpumask_and(data->cpumask, mask, cpu_online_mask);
  	cpumask_clear_cpu(this_cpu, data->cpumask);
- 	refs = cpumask_weight(data->cpumask);
  
  	/* Some callers race with other cpus changing the passed mask */
- 	if (unlikely(!refs)) {
- 		csd_unlock(&data->csd);
+ 	if (unlikely(!cpumask_weight(data->cpumask)))
  		return;
- 	}
  
 +	/*
 +	 * After we put an entry into the list, data->cpumask
 +	 * may be cleared again when another CPU sends another IPI for
 +	 * a SMP function call, so data->cpumask will be zero.
 +	 */
 +	cpumask_copy(data->cpumask_ipi, data->cpumask);
- 	raw_spin_lock_irqsave(&call_function.lock, flags);
- 	/*
- 	 * Place entry at the _HEAD_ of the list, so that any cpu still
- 	 * observing the entry in generic_smp_call_function_interrupt()
- 	 * will not miss any other list entries:
- 	 */
- 	list_add_rcu(&data->csd.list, &call_function.queue);
- 	/*
- 	 * We rely on the wmb() in list_add_rcu to complete our writes
- 	 * to the cpumask before this write to refs, which indicates
- 	 * data is on the list and is ready to be processed.
- 	 */
- 	atomic_set(&data->refs, refs);
- 	raw_spin_unlock_irqrestore(&call_function.lock, flags);
- 
- 	/*
- 	 * Make the list addition visible before sending the ipi.
- 	 * (IPIs must obey or appear to obey normal Linux cache
- 	 * coherency rules -- see comment in generic_exec_single).
- 	 */
- 	smp_mb();
+ 	for_each_cpu(cpu, data->cpumask) {
+ 		struct call_single_data *csd = per_cpu_ptr(data->csd, cpu);
+ 		struct call_single_queue *dst =
+ 					&per_cpu(call_single_queue, cpu);
+ 		unsigned long flags;
+ 
+ 		csd_lock(csd);
+ 		csd->func = func;
+ 		csd->info = info;
+ 
+ 		raw_spin_lock_irqsave(&dst->lock, flags);
+ 		list_add_tail(&csd->list, &dst->list);
+ 		raw_spin_unlock_irqrestore(&dst->lock, flags);
+ 	}
  
  	/* Send a message to all CPUs in the map */
 -	arch_send_call_function_ipi_mask(data->cpumask);
 +	arch_send_call_function_ipi_mask(data->cpumask_ipi);
  
- 	/* Optionally wait for the CPUs to complete */
- 	if (wait)
- 		csd_lock_wait(&data->csd);
+ 	if (wait) {
+ 		for_each_cpu(cpu, data->cpumask) {
+ 			struct call_single_data *csd =
+ 					per_cpu_ptr(data->csd, cpu);
+ 			csd_lock_wait(csd);
+ 		}
+ 	}
  }
  EXPORT_SYMBOL(smp_call_function_many);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
between commit  ("2083d67027ad") from the tip tree and commit "thp:
change split_huge_page_pmd() interface" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mprotect.c
index b5be3f1,d74a6fb..0000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -126,8 -89,8 +126,8 @@@ static inline unsigned long change_pmd_
  		next = pmd_addr_end(addr, end);
  		if (pmd_trans_huge(*pmd)) {
  			if (next - addr != HPAGE_PMD_SIZE)
- 				split_huge_page_pmd(vma->vm_mm, pmd);
+ 				split_huge_page_pmd(vma, addr, pmd);
 -			else if (change_huge_pmd(vma, pmd, addr, newprot)) {
 +			else if (change_huge_pmd(vma, pmd, addr, newprot, prot_numa)) {
  				pages += HPAGE_PMD_NR;
  				continue;
  			}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]


hi Stephen,

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
> between commit  ("2083d67027ad") from the tip tree and commit "thp:
> change split_huge_page_pmd() interface" from the akpm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I pre-checked linux-next on Friday, and the attached tarball 
with updated akpm patches needed conflict resolutions.

0178-mm-mempolicy-remove-duplicate-code.patch can be dropped I 
think.

Note that the merges are not tested though, so it's a JFYI.

Assuming the akpm tree still has roughly the same structure as 
the last linux-next tree had.

Thanks,

	Ingo

[-- Attachment #2: tip-merged-for-akpm.tar.gz --]
[-- Type: application/x-gzip, Size: 10652 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 2083d67027ad ("mm/mempolicy: Implement
change_prot_numa() in terms of change_protection()") from the tip,  tree
and commit "thp: change_huge_pmd(): make sure we don't try to make a page
writable" from the akpm tree.

I fixed it up (I think - see below) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/migrate.h
index bcb5ddc,50d2974..0000000
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@@ -7,16 -7,13 +7,23 @@@
  
  typedef struct page *new_page_t(struct page *, unsigned long private, int **);
  
 +enum migrate_reason {
 +	MR_COMPACTION,
 +	MR_MEMORY_FAILURE,
 +	MR_MEMORY_HOTPLUG,
 +	MR_SYSCALL,		/* also applies to cpusets */
 +	MR_MEMPOLICY_MBIND,
 +	MR_NUMA_MISPLACED,
 +	MR_CMA
 +};
 +
+ /*
+  * Return values from addresss_space_operations.migratepage():
+  * - negative errno on page migration failure;
+  * - zero on page migration success;
+  */
+ #define MIGRATEPAGE_SUCCESS		0
+ 
  #ifdef CONFIG_MIGRATION
  
  extern void putback_lru_pages(struct list_head *l);
diff --cc mm/migrate.c
index c0afe60,c3724b6..0000000
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@@ -981,8 -977,7 +981,8 @@@ int migrate_pages(struct list_head *fro
  			case -EAGAIN:
  				retry++;
  				break;
- 			case 0:
+ 			case MIGRATEPAGE_SUCCESS:
 +				nr_succeeded++;
  				break;
  			default:
  				/* Permanent failure */
@@@ -991,14 -986,8 +991,14 @@@
  			}
  		}
  	}
- 	rc = 0;
+ 	rc = nr_failed + retry;
  out:
 +	if (nr_succeeded)
 +		count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
 +	if (nr_failed)
 +		count_vm_events(PGMIGRATE_FAIL, nr_failed);
 +	trace_mm_migrate_pages(nr_succeeded, nr_failed, mode, reason);
 +
  	if (!swapwrite)
  		current->flags &= ~PF_SWAPWRITE;
  
diff --cc mm/huge_memory.c
index 2c4e4d4,28a368c..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1352,17 -1433,8 +1352,18 @@@ int change_huge_pmd(struct vm_area_stru
  	if (__pmd_trans_huge_lock(pmd, vma) == 1) {
  		pmd_t entry;
  		entry = pmdp_get_and_clear(mm, addr, pmd);
 -		entry = pmd_modify(entry, newprot);
 +		if (!prot_numa)
 +			entry = pmd_modify(entry, newprot);
 +		else {
 +			struct page *page = pmd_page(*pmd);
 +
 +			/* only check non-shared pages */
 +			if (page_mapcount(page) == 1 &&
 +			    !pmd_numa(*pmd)) {
 +				entry = pmd_mknuma(entry);
 +			}
 +		}
+ 		BUG_ON(pmd_write(entry));
  		set_pmd_at(mm, addr, pmd, entry);
  		spin_unlock(&vma->vm_mm->page_table_lock);
  		ret = 1;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit d9f1eb872704 ("numa, mempolicy: Improve
CONFIG_NUMA_BALANCING=y OOM behavior") from the tip tree and commit "mm,
mempolicy: remove duplicate code" from the akpm tree.

I can't tell if the akpm tree patch is still relevant, so I dropped it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in mm/migrate.c
and include/linux/migrate.h between commits 070059b28578 ("mm/compaction:
Move migration fail/success stats to migrate.c") and 2d85cca46951
("mm/migrate: Add a tracepoint for migrate_pages") from the tip tree and
commit "mm: adjust address_space_operations.migratepage() return code"
from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/migrate.h
index bcb5ddc,50d2974..0000000
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@@ -7,16 -7,13 +7,23 @@@
  
  typedef struct page *new_page_t(struct page *, unsigned long private, int **);
  
 +enum migrate_reason {
 +	MR_COMPACTION,
 +	MR_MEMORY_FAILURE,
 +	MR_MEMORY_HOTPLUG,
 +	MR_SYSCALL,		/* also applies to cpusets */
 +	MR_MEMPOLICY_MBIND,
 +	MR_NUMA_MISPLACED,
 +	MR_CMA
 +};
 +
+ /*
+  * Return values from addresss_space_operations.migratepage():
+  * - negative errno on page migration failure;
+  * - zero on page migration success;
+  */
+ #define MIGRATEPAGE_SUCCESS		0
+ 
  #ifdef CONFIG_MIGRATION
  
  extern void putback_lru_pages(struct list_head *l);
diff --cc mm/migrate.c
index c0afe60,c3724b6..0000000
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@@ -981,8 -977,7 +981,8 @@@ int migrate_pages(struct list_head *fro
  			case -EAGAIN:
  				retry++;
  				break;
- 			case 0:
+ 			case MIGRATEPAGE_SUCCESS:
 +				nr_succeeded++;
  				break;
  			default:
  				/* Permanent failure */
@@@ -991,14 -986,8 +991,14 @@@
  			}
  		}
  	}
- 	rc = 0;
+ 	rc = nr_failed + retry;
  out:
 +	if (nr_succeeded)
 +		count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
 +	if (nr_failed)
 +		count_vm_events(PGMIGRATE_FAIL, nr_failed);
 +	trace_mm_migrate_pages(nr_succeeded, nr_failed, mode, reason);
 +
  	if (!swapwrite)
  		current->flags &= ~PF_SWAPWRITE;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in mm/memory.c
between changes in commits from the tip tree and commit "mm: thp: set the
accessed flag for old pages on access fault" from the akpm tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/memory.c
index 8022526,60201d5..0000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -3812,15 -3620,18 +3812,17 @@@ retry
  							  pmd, flags);
  	} else {
  		pmd_t orig_pmd = *pmd;
 -		int ret = 0;
 +		int ret;
  
  		barrier();
 -		if (pmd_trans_huge(orig_pmd) && !pmd_trans_splitting(orig_pmd)) {
 +		if (pmd_trans_huge(orig_pmd)) {
+ 			unsigned int dirty = flags & FAULT_FLAG_WRITE;
+ 
 -			if (pmd_numa(vma, orig_pmd)) {
 -				do_huge_pmd_numa_page(mm, vma, address, pmd,
 -						      flags, orig_pmd);
 -			}
 +			if (pmd_numa(*pmd))
 +				return do_huge_pmd_numa_page(mm, vma, address,
 +							     orig_pmd, pmd);
  
- 			if ((flags & FAULT_FLAG_WRITE) && !pmd_write(orig_pmd)) {
+ 			if (dirty && !pmd_write(orig_pmd)) {
  				ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
  							  orig_pmd);
  				/*
@@@ -3830,10 -3641,12 +3832,13 @@@
  				 */
  				if (unlikely(ret & VM_FAULT_OOM))
  					goto retry;
 +				return ret;
+ 			} else {
+ 				huge_pmd_set_accessed(mm, vma, address, pmd,
+ 						      orig_pmd, dirty);
  			}
  
 -			return ret;
 +			return 0;
  		}
  	}
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Will Deacon]

Hi guys,

On Mon, Dec 10, 2012 at 08:01:39AM +0000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in mm/memory.c
> between changes in commits from the tip tree and commit "mm: thp: set the
> accessed flag for old pages on access fault" from the akpm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

[...]

> diff --cc mm/memory.c
> index 8022526,60201d5..0000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@@ -3812,15 -3620,18 +3812,17 @@@ retry
>   							  pmd, flags);
>   	} else {
>   		pmd_t orig_pmd = *pmd;
>  -		int ret = 0;
>  +		int ret;
>   
>   		barrier();
>  -		if (pmd_trans_huge(orig_pmd) && !pmd_trans_splitting(orig_pmd)) {
>  +		if (pmd_trans_huge(orig_pmd)) {

This change worries me a bit wrt the huge_pmd_set_accessed function I
introduce below. Unfortunately, current -next doesn't seem to include it, so
I can't see whether do_huge_pmd_numa_page / do_huge_pmd_wp_page have been
changed to deal with the splitting or whether the check has been moved
earlier.

Will

> + 			unsigned int dirty = flags & FAULT_FLAG_WRITE;
> + 
>  -			if (pmd_numa(vma, orig_pmd)) {
>  -				do_huge_pmd_numa_page(mm, vma, address, pmd,
>  -						      flags, orig_pmd);
>  -			}
>  +			if (pmd_numa(*pmd))
>  +				return do_huge_pmd_numa_page(mm, vma, address,
>  +							     orig_pmd, pmd);
>   
> - 			if ((flags & FAULT_FLAG_WRITE) && !pmd_write(orig_pmd)) {
> + 			if (dirty && !pmd_write(orig_pmd)) {
>   				ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
>   							  orig_pmd);
>   				/*
> @@@ -3830,10 -3641,12 +3832,13 @@@
>   				 */
>   				if (unlikely(ret & VM_FAULT_OOM))
>   					goto retry;
>  +				return ret;
> + 			} else {
> + 				huge_pmd_set_accessed(mm, vma, address, pmd,
> + 						      orig_pmd, dirty);
>   			}
>   
>  -			return ret;
>  +			return 0;
>   		}
>   	}
>   

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between various commits from the tip tree and commit
"thp: fix update_mmu_cache_pmd() calls" from the akpm tree.

It appears that the shed/numa patches in the tip tree have been changed
in today's version of the tip tree and this akpm tree patch no longer
applies.

I dropped the akpm tree patch and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
between commit a9463d90124a ("mm: Count the number of pages affected in
change_protection()") from the tip tree and commit "thp: change
split_huge_page_pmd() interface" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mprotect.c
index 6ff2d5e,cbafe4b..0000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -89,11 -83,9 +89,11 @@@ static inline unsigned long change_pmd_
  		next = pmd_addr_end(addr, end);
  		if (pmd_trans_huge(*pmd)) {
  			if (next - addr != HPAGE_PMD_SIZE)
- 				split_huge_page_pmd(vma->vm_mm, pmd);
+ 				split_huge_page_pmd(vma, addr, pmd);
 -			else if (change_huge_pmd(vma, pmd, addr, newprot))
 +			else if (change_huge_pmd(vma, pmd, addr, newprot)) {
 +				pages += HPAGE_PMD_NR;
  				continue;
 +			}
  			/* fall through */
  		}
  		if (pmd_none_or_clear_bad(pmd))

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit e9d5bc24d665 ("mm/mpol: Make mempolicy
home-node aware") from the tip tree and commit "mempolicy: fix a memory
corruption by refcount imbalance in alloc_pages_vma()" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mempolicy.c
index 6e2cd87,3c23d89..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -1603,7 -1587,8 +1603,8 @@@ asmlinkage long compat_sys_mbind(compat
  struct mempolicy *get_vma_policy(struct task_struct *task,
  		struct vm_area_struct *vma, unsigned long addr)
  {
 -	struct mempolicy *pol = task->mempolicy;
 +	struct mempolicy *pol = get_task_policy(task);
+ 	int got_ref;
  
  	if (vma) {
  		if (vma->vm_ops && vma->vm_ops->get_policy) {

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4824 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("93c9d633bd9e") from the
tip tree and commit "thp: introduce pmdp_invalidate()" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/huge_memory.c
index 9267537,56f9443..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1384,55 -1312,59 +1384,54 @@@ static int __split_huge_page_map(struc
  	spin_lock(&mm->page_table_lock);
  	pmd = page_check_address_pmd(page, mm, address,
  				     PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
 -	if (pmd) {
 -		pgtable = pgtable_trans_huge_withdraw(mm);
 -		pmd_populate(mm, &_pmd, pgtable);
 -
 -		for (i = 0, haddr = address; i < HPAGE_PMD_NR;
 -		     i++, haddr += PAGE_SIZE) {
 -			pte_t *pte, entry;
 -			BUG_ON(PageCompound(page+i));
 -			entry = mk_pte(page + i, vma->vm_page_prot);
 -			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
 -			if (!pmd_write(*pmd))
 -				entry = pte_wrprotect(entry);
 -			else
 -				BUG_ON(page_mapcount(page) != 1);
 -			if (!pmd_young(*pmd))
 -				entry = pte_mkold(entry);
 -			pte = pte_offset_map(&_pmd, haddr);
 -			BUG_ON(!pte_none(*pte));
 -			set_pte_at(mm, haddr, pte, entry);
 -			pte_unmap(pte);
 -		}
 +	if (!pmd)
 +		goto unlock;
  
 -		smp_wmb(); /* make pte visible before pmd */
 -		/*
 -		 * Up to this point the pmd is present and huge and
 -		 * userland has the whole access to the hugepage
 -		 * during the split (which happens in place). If we
 -		 * overwrite the pmd with the not-huge version
 -		 * pointing to the pte here (which of course we could
 -		 * if all CPUs were bug free), userland could trigger
 -		 * a small page size TLB miss on the small sized TLB
 -		 * while the hugepage TLB entry is still established
 -		 * in the huge TLB. Some CPU doesn't like that. See
 -		 * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
 -		 * Erratum 383 on page 93. Intel should be safe but is
 -		 * also warns that it's only safe if the permission
 -		 * and cache attributes of the two entries loaded in
 -		 * the two TLB is identical (which should be the case
 -		 * here). But it is generally safer to never allow
 -		 * small and huge TLB entries for the same virtual
 -		 * address to be loaded simultaneously. So instead of
 -		 * doing "pmd_populate(); flush_tlb_range();" we first
 -		 * mark the current pmd notpresent (atomically because
 -		 * here the pmd_trans_huge and pmd_trans_splitting
 -		 * must remain set at all times on the pmd until the
 -		 * split is complete for this pmd), then we flush the
 -		 * SMP TLB and finally we write the non-huge version
 -		 * of the pmd entry with pmd_populate.
 -		 */
 -		pmdp_invalidate(vma, address, pmd);
 -		pmd_populate(mm, pmd, pgtable);
 -		ret = 1;
 +	prot = pmd_pgprot(*pmd);
 +	pgtable = pgtable_trans_huge_withdraw(mm);
 +	pmd_populate(mm, &_pmd, pgtable);
 +
 +	for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
 +		pte_t *pte, entry;
 +
 +		BUG_ON(PageCompound(page+i));
 +		entry = mk_pte(page + i, prot);
 +		entry = pte_mkdirty(entry);
 +		if (!pmd_young(*pmd))
 +			entry = pte_mkold(entry);
 +		pte = pte_offset_map(&_pmd, haddr);
 +		BUG_ON(!pte_none(*pte));
 +		set_pte_at(mm, haddr, pte, entry);
 +		pte_unmap(pte);
  	}
 +
 +	smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
 +	/*
 +	 * Up to this point the pmd is present and huge.
 +	 *
 +	 * If we overwrite the pmd with the not-huge version, we could trigger
 +	 * a small page size TLB miss on the small sized TLB while the hugepage
 +	 * TLB entry is still established in the huge TLB.
 +	 *
 +	 * Some CPUs don't like that. See
 +	 * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
 +	 * on page 93.
 +	 *
 +	 * Thus it is generally safer to never allow small and huge TLB entries
 +	 * for overlapping virtual addresses to be loaded. So we first mark the
 +	 * current pmd not present, then we flush the TLB and finally we write
 +	 * the non-huge version of the pmd entry with pmd_populate.
 +	 *
 +	 * The above needs to be done under the ptl because pmd_trans_huge and
 +	 * pmd_trans_splitting must remain set on the pmd until the split is
 +	 * complete. The ptl also protects against concurrent faults due to
 +	 * making the pmd not-present.
 +	 */
- 	set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
- 	flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
++	pmdp_invalidate(vma, address, pmd);
 +	pmd_populate(mm, pmd, pgtable);
 +	ret = 1;
 +
 +unlock:
  	spin_unlock(&mm->page_table_lock);
  
  	return ret;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("mm/thp: Preserve pgprot
across huge page split") from the tip tree and commit  ("thp: remove
assumptions on pgtable_t type") from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/huge_memory.c
index 6b176fe,a91bc3c..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1416,55 -1312,60 +1384,55 @@@ static int __split_huge_page_map(struc
  	spin_lock(&mm->page_table_lock);
  	pmd = page_check_address_pmd(page, mm, address,
  				     PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
 -	if (pmd) {
 -		pgtable = pgtable_trans_huge_withdraw(mm);
 -		pmd_populate(mm, &_pmd, pgtable);
 -
 -		for (i = 0, haddr = address; i < HPAGE_PMD_NR;
 -		     i++, haddr += PAGE_SIZE) {
 -			pte_t *pte, entry;
 -			BUG_ON(PageCompound(page+i));
 -			entry = mk_pte(page + i, vma->vm_page_prot);
 -			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
 -			if (!pmd_write(*pmd))
 -				entry = pte_wrprotect(entry);
 -			else
 -				BUG_ON(page_mapcount(page) != 1);
 -			if (!pmd_young(*pmd))
 -				entry = pte_mkold(entry);
 -			pte = pte_offset_map(&_pmd, haddr);
 -			BUG_ON(!pte_none(*pte));
 -			set_pte_at(mm, haddr, pte, entry);
 -			pte_unmap(pte);
 -		}
 +	if (!pmd)
 +		goto unlock;
  
 -		smp_wmb(); /* make pte visible before pmd */
 -		/*
 -		 * Up to this point the pmd is present and huge and
 -		 * userland has the whole access to the hugepage
 -		 * during the split (which happens in place). If we
 -		 * overwrite the pmd with the not-huge version
 -		 * pointing to the pte here (which of course we could
 -		 * if all CPUs were bug free), userland could trigger
 -		 * a small page size TLB miss on the small sized TLB
 -		 * while the hugepage TLB entry is still established
 -		 * in the huge TLB. Some CPU doesn't like that. See
 -		 * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
 -		 * Erratum 383 on page 93. Intel should be safe but is
 -		 * also warns that it's only safe if the permission
 -		 * and cache attributes of the two entries loaded in
 -		 * the two TLB is identical (which should be the case
 -		 * here). But it is generally safer to never allow
 -		 * small and huge TLB entries for the same virtual
 -		 * address to be loaded simultaneously. So instead of
 -		 * doing "pmd_populate(); flush_tlb_range();" we first
 -		 * mark the current pmd notpresent (atomically because
 -		 * here the pmd_trans_huge and pmd_trans_splitting
 -		 * must remain set at all times on the pmd until the
 -		 * split is complete for this pmd), then we flush the
 -		 * SMP TLB and finally we write the non-huge version
 -		 * of the pmd entry with pmd_populate.
 -		 */
 -		set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
 -		flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
 -		pmd_populate(mm, pmd, pgtable);
 -		ret = 1;
 +	prot = pmd_pgprot(*pmd);
- 	pgtable = get_pmd_huge_pte(mm);
++	pgtable = pgtable_trans_huge_withdraw(mm);
 +	pmd_populate(mm, &_pmd, pgtable);
 +
 +	for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
 +		pte_t *pte, entry;
 +
 +		BUG_ON(PageCompound(page+i));
 +		entry = mk_pte(page + i, prot);
 +		entry = pte_mkdirty(entry);
 +		if (!pmd_young(*pmd))
 +			entry = pte_mkold(entry);
 +		pte = pte_offset_map(&_pmd, haddr);
 +		BUG_ON(!pte_none(*pte));
 +		set_pte_at(mm, haddr, pte, entry);
 +		pte_unmap(pte);
  	}
 +
 +	smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
 +	/*
 +	 * Up to this point the pmd is present and huge.
 +	 *
 +	 * If we overwrite the pmd with the not-huge version, we could trigger
 +	 * a small page size TLB miss on the small sized TLB while the hugepage
 +	 * TLB entry is still established in the huge TLB.
 +	 *
 +	 * Some CPUs don't like that. See
 +	 * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
 +	 * on page 93.
 +	 *
 +	 * Thus it is generally safer to never allow small and huge TLB entries
 +	 * for overlapping virtual addresses to be loaded. So we first mark the
 +	 * current pmd not present, then we flush the TLB and finally we write
 +	 * the non-huge version of the pmd entry with pmd_populate.
 +	 *
 +	 * The above needs to be done under the ptl because pmd_trans_huge and
 +	 * pmd_trans_splitting must remain set on the pmd until the split is
 +	 * complete. The ptl also protects against concurrent faults due to
 +	 * making the pmd not-present.
 +	 */
 +	set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
 +	flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
 +	pmd_populate(mm, pmd, pgtable);
 +	ret = 1;
 +
 +unlock:
  	spin_unlock(&mm->page_table_lock);
  
  	return ret;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("mm/thp: Preserve pgprot
across huge page split") from the tip tree and commit "thp: merge page
pre-alloc in khugepaged_loop into khugepaged_do_scan" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/huge_memory.c
index 5ab8c26,50bd2ac..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -2307,11 -2240,43 +2307,41 @@@ static int khugepaged_wait_event(void
  		kthread_should_stop();
  }
  
- static void khugepaged_do_scan(struct page **hpage)
+ static void khugepaged_alloc_sleep(void)
+ {
+ 	wait_event_freezable_timeout(khugepaged_wait, false,
+ 			msecs_to_jiffies(khugepaged_alloc_sleep_millisecs));
+ }
+ 
+ #ifndef CONFIG_NUMA
+ static struct page *khugepaged_alloc_hugepage(bool *wait)
+ {
+ 	struct page *hpage;
+ 
+ 	do {
+ 		hpage = alloc_hugepage(khugepaged_defrag());
+ 		if (!hpage) {
+ 			count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
+ 			if (!*wait)
+ 				return NULL;
+ 
+ 			*wait = false;
+ 			khugepaged_alloc_sleep();
+ 		} else
+ 			count_vm_event(THP_COLLAPSE_ALLOC);
+ 	} while (unlikely(!hpage) && likely(khugepaged_enabled()));
+ 
+ 	return hpage;
+ }
+ #endif
+ 
+ static void khugepaged_do_scan(void)
  {
+ 	struct page *hpage = NULL;
  	unsigned int progress = 0, pass_through_head = 0;
 -	unsigned int pages = khugepaged_pages_to_scan;
 +	unsigned int pages = ACCESS_ONCE(khugepaged_pages_to_scan);
+ 	bool wait = true;
  
 -	barrier(); /* write khugepaged_pages_to_scan to local stack */
 -
  	while (progress < pages) {
  		cond_resched();
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit 4d58c795f691 ("mm/mpol: Check for misplaced
page") from the tip tree and commit "mempolicy: fix refcount leak in
mpol_set_shared_policy()" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/mempolicy.c
index a0eec0e,1763418..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -2174,82 -2157,12 +2174,88 @@@ mpol_shared_policy_lookup(struct shared
  	return pol;
  }
  
 +/**
 + * mpol_misplaced - check whether current page node is valid in policy
 + *
 + * @page   - page to be checked
 + * @vma    - vm area where page mapped
 + * @addr   - virtual address where page mapped
 + *
 + * Lookup current policy node id for vma,addr and "compare to" page's
 + * node id.
 + *
 + * Returns:
 + *	-1	- not misplaced, page is in the right node
 + *	node	- node id where the page should be
 + *
 + * Policy determination "mimics" alloc_page_vma().
 + * Called from fault path where we know the vma and faulting address.
 + */
 +int mpol_misplaced(struct page *page, struct vm_area_struct *vma, unsigned long addr)
 +{
 +	struct mempolicy *pol;
 +	struct zone *zone;
 +	int curnid = page_to_nid(page);
 +	unsigned long pgoff;
 +	int polnid = -1;
 +	int ret = -1;
 +
 +	BUG_ON(!vma);
 +
 +	pol = get_vma_policy(current, vma, addr);
 +	if (!(pol->flags & MPOL_F_MOF))
 +		goto out;
 +
 +	switch (pol->mode) {
 +	case MPOL_INTERLEAVE:
 +		BUG_ON(addr >= vma->vm_end);
 +		BUG_ON(addr < vma->vm_start);
 +
 +		pgoff = vma->vm_pgoff;
 +		pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
 +		polnid = offset_il_node(pol, vma, pgoff);
 +		break;
 +
 +	case MPOL_PREFERRED:
 +		if (pol->flags & MPOL_F_LOCAL)
 +			polnid = numa_node_id();
 +		else
 +			polnid = pol->v.preferred_node;
 +		break;
 +
 +	case MPOL_BIND:
 +		/*
 +		 * allows binding to multiple nodes.
 +		 * use current page if in policy nodemask,
 +		 * else select nearest allowed node, if any.
 +		 * If no allowed nodes, use current [!misplaced].
 +		 */
 +		if (node_isset(curnid, pol->v.nodes))
 +			goto out;
 +		(void)first_zones_zonelist(
 +				node_zonelist(numa_node_id(), GFP_HIGHUSER),
 +				gfp_zone(GFP_HIGHUSER),
 +				&pol->v.nodes, &zone);
 +		polnid = zone->node;
 +		break;
 +
 +	default:
 +		BUG();
 +	}
 +	if (curnid != polnid)
 +		ret = polnid;
 +out:
 +	mpol_cond_put(pol);
 +
 +	return ret;
 +}
 +
+ static void sp_free(struct sp_node *n)
+ {
+ 	mpol_put(n->policy);
+ 	kmem_cache_free(sn_cache, n);
+ }
+ 
  static void sp_delete(struct shared_policy *sp, struct sp_node *n)
  {
  	pr_debug("deleting %lx-l%lx\n", n->start, n->end);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
include/linux/mm.h between commit 1dbd3d35fe64 ("mm/pgprot: Move the
pgprot_modify() fallback definition to mm.h") from the tip tree and
commit "mm, x86, pat: rework linear pfn-mmap tracking" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/mm.h
index 4adea2c,a66f646..0000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -160,37 -160,6 +160,19 @@@ extern pgprot_t protection_map[16]
  #define FAULT_FLAG_TRIED	0x40	/* second try */
  
  /*
-  * This interface is used by x86 PAT code to identify a pfn mapping that is
-  * linear over entire vma. This is to optimize PAT code that deals with
-  * marking the physical region with a particular prot. This is not for generic
-  * mm use. Note also that this check will not work if the pfn mapping is
-  * linear for a vma starting at physical address 0. In which case PAT code
-  * falls back to slow path of reserving physical range page by page.
-  */
- static inline int is_linear_pfn_mapping(struct vm_area_struct *vma)
- {
- 	return !!(vma->vm_flags & VM_PFN_AT_MMAP);
- }
- 
- static inline int is_pfn_mapping(struct vm_area_struct *vma)
- {
- 	return !!(vma->vm_flags & VM_PFNMAP);
- }
- 
- /*
 + * Some architectures (such as x86) may need to preserve certain pgprot
 + * bits, without complicating generic pgprot code.
 + *
 + * Most architectures don't care:
 + */
 +#ifndef pgprot_modify
 +static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
 +{
 +	return newprot;
 +}
 +#endif
 +
 +/*
   * vm_fault is filled by the the pagefault handler and passed to the vma's
   * ->fault function. The vma's ->fault is responsible for returning a bitmask
   * of VM_FAULT_xxx flags that give details about how the fault was handled.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_uncore.h between commit 254298c726b9
("perf/x86: Add Intel Nehalem-EX uncore support") from the tip tree and
commit "arch/x86/kernel/cpu/perf_event_intel_uncore.h: make
UNCORE_PMU_HRTIMER_INTERVAL 64-bit" from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/cpu/perf_event_intel_uncore.h
index f385189,d85c25d..0000000
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@@ -5,7 -5,9 +5,7 @@@
  #include "perf_event.h"
  
  #define UNCORE_PMU_NAME_LEN		32
- #define UNCORE_PMU_HRTIMER_INTERVAL	(60 * NSEC_PER_SEC)
 -#define UNCORE_BOX_HASH_SIZE		8
 -
+ #define UNCORE_PMU_HRTIMER_INTERVAL	(60LL * NSEC_PER_SEC)
  
  #define UNCORE_FIXED_EVENT		0xff
  #define UNCORE_PMC_IDX_MAX_GENERIC	8

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in mm/migrate.c
between the tip tree and commit "mm: memcg: fix compaction/migration
failing due to memcg limits" from the akpm tree.

The commit 4783af477d3d ("mm: Migrate misplaced page") was removed (among
several others) from the tip tree since yesterday (and thus linux-next)
so the above akpm tree patch no longer applies.

I have dropped this patch form the akpm tree (and the following patches
as well:
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
mm: memcg: push down PageSwapCache check into uncharge entry functions
mm: memcg: only check for PageSwapCache when uncharging anon
mm: memcg: remove unneeded shmem charge type
mm: memcg: remove needless !mm fixup to init_mm when charging
)

Hopefully this doesn't cause other problems.  I guess that they will need
rebasing depending on what gets merged via the tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in 
> mm/migrate.c between the tip tree and commit "mm: memcg: fix 
> compaction/migration failing due to memcg limits" from the 
> akpm tree.
> 
> The commit 4783af477d3d ("mm: Migrate misplaced page") was 
> removed (among several others) from the tip tree since 
> yesterday (and thus linux-next) so the above akpm tree patch 
> no longer applies.
> 
> I have dropped this patch form the akpm tree (and the following patches
> as well:
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> mm: memcg: push down PageSwapCache check into uncharge entry functions
> mm: memcg: only check for PageSwapCache when uncharging anon
> mm: memcg: remove unneeded shmem charge type
> mm: memcg: remove needless !mm fixup to init_mm when charging
> )
> 
> Hopefully this doesn't cause other problems.  I guess that 
> they will need rebasing depending on what gets merged via the 
> tip tree.

Andrew, sorry about this last minute fallout: I felt that 
sched/numa was still not fully cooked and did not want to hold 
up the rest of the scheduler tree on that - nor did I want to 
send an uncooked tree to Linus.

PeterZ posted another series of sched/numa patches two days ago 
- once that is ready (probably after the merge window) it will 
all reappear again, in a slightly different form. I could stick 
the mm/ bits into a separate tree to make it easier for you.

Cross-discipline patches are hard - the other option would be to 
let Linux NUMA scheduling continue to suck.

Thanks,

	Ingo

Re: linux-next: manual merge of the akpm tree with the tip tree

[Johannes Weiner]

On Wed, Jul 25, 2012 at 09:10:44AM +0200, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm tree got a conflict in 
> > mm/migrate.c between the tip tree and commit "mm: memcg: fix 
> > compaction/migration failing due to memcg limits" from the 
> > akpm tree.
> > 
> > The commit 4783af477d3d ("mm: Migrate misplaced page") was 
> > removed (among several others) from the tip tree since 
> > yesterday (and thus linux-next) so the above akpm tree patch 
> > no longer applies.
> > 
> > I have dropped this patch form the akpm tree (and the following patches
> > as well:
> > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> > mm: memcg: push down PageSwapCache check into uncharge entry functions
> > mm: memcg: only check for PageSwapCache when uncharging anon
> > mm: memcg: remove unneeded shmem charge type
> > mm: memcg: remove needless !mm fixup to init_mm when charging
> > )
> > 
> > Hopefully this doesn't cause other problems.  I guess that 
> > they will need rebasing depending on what gets merged via the 
> > tip tree.
> 
> Andrew, sorry about this last minute fallout: I felt that 
> sched/numa was still not fully cooked and did not want to hold 
> up the rest of the scheduler tree on that - nor did I want to 
> send an uncooked tree to Linus.
> 
> PeterZ posted another series of sched/numa patches two days ago 
> - once that is ready (probably after the merge window) it will 
> all reappear again, in a slightly different form. I could stick 
> the mm/ bits into a separate tree to make it easier for you.

As this is unlikely to reappear in this merge window, the conflict
resolution is quite simple.  All that's needed is remove the 3 hunks
from my patch that converted a user in Peter's patch to a new API.  I
can resend the series if needed, but it's probably easier to just
remove the hunks against mm/migrate.c::migrate_misplaced_page():

@@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
 {
 	struct page *oldpage = page, *newpage;
 	struct address_space *mapping = page_mapping(page);
-	struct mem_cgroup *mcg;
+	struct mem_cgroup *memcg;
 	unsigned int gfp;
 	int rc = 0;
-	int charge = -ENOMEM;
 
 	VM_BUG_ON(!PageLocked(page));
 	VM_BUG_ON(page_mapcount(page));
@@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
 	if (!trylock_page(newpage))
 		BUG();		/* new page should be unlocked!!! */
 
-	// XXX hnaz, is this right?
-	charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
-	if (charge == -ENOMEM) {
-		rc = charge;
-		goto out;
-	}
+	mem_cgroup_prepare_migration(page, newpage, &memcg);
 
 	newpage->index = page->index;
 	newpage->mapping = page->mapping;
@@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
 		page = newpage;
 	}
 
+	mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
 out:
-	if (!charge)
-		mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
-
-       if (oldpage != page)
+	if (oldpage != page)
                put_page(oldpage);
 
 	if (rc) {

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Wed, 25 Jul 2012 09:35:03 +0200
Johannes Weiner <hannes@cmpxchg.org> wrote:

> As this is unlikely to reappear in this merge window, the conflict
> resolution is quite simple.  All that's needed is remove the 3 hunks
> from my patch that converted a user in Peter's patch to a new API.  I
> can resend the series if needed, but it's probably easier to just
> remove the hunks against mm/migrate.c::migrate_misplaced_page():
> 
> @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
>  {
>  	struct page *oldpage = page, *newpage;
>  	struct address_space *mapping = page_mapping(page);
> -	struct mem_cgroup *mcg;
> +	struct mem_cgroup *memcg;
>  	unsigned int gfp;
>  	int rc = 0;
> -	int charge = -ENOMEM;
>  
>  	VM_BUG_ON(!PageLocked(page));
>  	VM_BUG_ON(page_mapcount(page));
> @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
>  	if (!trylock_page(newpage))
>  		BUG();		/* new page should be unlocked!!! */
>  
> -	// XXX hnaz, is this right?
> -	charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> -	if (charge == -ENOMEM) {
> -		rc = charge;
> -		goto out;
> -	}
> +	mem_cgroup_prepare_migration(page, newpage, &memcg);
>  
>  	newpage->index = page->index;
>  	newpage->mapping = page->mapping;
> @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
>  		page = newpage;
>  	}
>  
> +	mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
>  out:
> -	if (!charge)
> -		mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> -
> -       if (oldpage != page)
> +	if (oldpage != page)
>                 put_page(oldpage);
>  
>  	if (rc) {

Yes, that worked out OK.

This means that if the above code reappears in linux-next or mainline,
the current copy of
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
will no longer update it, and I probably won't notice that omission. 

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 25 Jul 2012 09:35:03 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > As this is unlikely to reappear in this merge window, the conflict
> > resolution is quite simple.  All that's needed is remove the 3 hunks
> > from my patch that converted a user in Peter's patch to a new API.  I
> > can resend the series if needed, but it's probably easier to just
> > remove the hunks against mm/migrate.c::migrate_misplaced_page():
> > 
> > @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  {
> >  	struct page *oldpage = page, *newpage;
> >  	struct address_space *mapping = page_mapping(page);
> > -	struct mem_cgroup *mcg;
> > +	struct mem_cgroup *memcg;
> >  	unsigned int gfp;
> >  	int rc = 0;
> > -	int charge = -ENOMEM;
> >  
> >  	VM_BUG_ON(!PageLocked(page));
> >  	VM_BUG_ON(page_mapcount(page));
> > @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  	if (!trylock_page(newpage))
> >  		BUG();		/* new page should be unlocked!!! */
> >  
> > -	// XXX hnaz, is this right?
> > -	charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> > -	if (charge == -ENOMEM) {
> > -		rc = charge;
> > -		goto out;
> > -	}
> > +	mem_cgroup_prepare_migration(page, newpage, &memcg);
> >  
> >  	newpage->index = page->index;
> >  	newpage->mapping = page->mapping;
> > @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  		page = newpage;
> >  	}
> >  
> > +	mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> >  out:
> > -	if (!charge)
> > -		mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> > -
> > -       if (oldpage != page)
> > +	if (oldpage != page)
> >                 put_page(oldpage);
> >  
> >  	if (rc) {
> 
> Yes, that worked out OK.
> 
> This means that if the above code reappears in linux-next or 
> mainline, the current copy of 
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch 
> will no longer update it, and I probably won't notice that 
> omission.

Did you plan to send Johannes's memcg bits to Linus in this 
merge window? If yes then I'll delay pushing out anything that 
might interfere.

Thanks,

	Ingo

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Wed, 25 Jul 2012 21:03:51 +0200
Ingo Molnar <mingo@kernel.org> wrote:

> > This means that if the above code reappears in linux-next or 
> > mainline, the current copy of 
> > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch 
> > will no longer update it, and I probably won't notice that 
> > omission.
> 
> Did you plan to send Johannes's memcg bits to Linus in this 
> merge window?

Yes.  I was kinda thinking of starting the bombing run on Monday but I
guess I could do the MM queue on Thursday.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 25 Jul 2012 21:03:51 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> > > This means that if the above code reappears in linux-next or 
> > > mainline, the current copy of 
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch 
> > > will no longer update it, and I probably won't notice that 
> > > omission.
> > 
> > Did you plan to send Johannes's memcg bits to Linus in this 
> > merge window?
> 
> Yes.  I was kinda thinking of starting the bombing run on 
> Monday but I guess I could do the MM queue on Thursday.

Ok, great, that simplifies things: we'll base any additional 
sched/numa work on an upstream sha1 that has those bits 
upstream. (-rc1, if upstream quality allows.)

Thanks,

	Ingo

Re: linux-next: manual merge of the akpm tree with the tip tree

[Andrew Morton]

On Wed, 25 Jul 2012 12:26:13 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 25 Jul 2012 21:03:51 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> > > This means that if the above code reappears in linux-next or 
> > > mainline, the current copy of 
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch 
> > > will no longer update it, and I probably won't notice that 
> > > omission.
> > 
> > Did you plan to send Johannes's memcg bits to Linus in this 
> > merge window?
> 
> Yes.  I was kinda thinking of starting the bombing run on Monday but I
> guess I could do the MM queue on Thursday.

Sorry, this didn't work out: there's still too much stuff which hasn't
gone into mainline yet (slab, NFS, others).  Merging the MM code now
would involve a worrying amount of last-minute code rework and would
cause the owners of those trees to have to do last-minute rework as
well.  This is why I always go last.

I'll take another look on Monday.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Johannes Weiner]

On Wed, Jul 25, 2012 at 11:57:13AM -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2012 09:35:03 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > As this is unlikely to reappear in this merge window, the conflict
> > resolution is quite simple.  All that's needed is remove the 3 hunks
> > from my patch that converted a user in Peter's patch to a new API.  I
> > can resend the series if needed, but it's probably easier to just
> > remove the hunks against mm/migrate.c::migrate_misplaced_page():
> > 
> > @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  {
> >  	struct page *oldpage = page, *newpage;
> >  	struct address_space *mapping = page_mapping(page);
> > -	struct mem_cgroup *mcg;
> > +	struct mem_cgroup *memcg;
> >  	unsigned int gfp;
> >  	int rc = 0;
> > -	int charge = -ENOMEM;
> >  
> >  	VM_BUG_ON(!PageLocked(page));
> >  	VM_BUG_ON(page_mapcount(page));
> > @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  	if (!trylock_page(newpage))
> >  		BUG();		/* new page should be unlocked!!! */
> >  
> > -	// XXX hnaz, is this right?
> > -	charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> > -	if (charge == -ENOMEM) {
> > -		rc = charge;
> > -		goto out;
> > -	}
> > +	mem_cgroup_prepare_migration(page, newpage, &memcg);
> >  
> >  	newpage->index = page->index;
> >  	newpage->mapping = page->mapping;
> > @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> >  		page = newpage;
> >  	}
> >  
> > +	mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> >  out:
> > -	if (!charge)
> > -		mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> > -
> > -       if (oldpage != page)
> > +	if (oldpage != page)
> >                 put_page(oldpage);
> >  
> >  	if (rc) {
> 
> Yes, that worked out OK.
> 
> This means that if the above code reappears in linux-next or mainline,
> the current copy of
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> will no longer update it, and I probably won't notice that omission. 

The gfp_t argument was dropped from mem_cgroup_prepare_migration(), so
it'll blow up during compilation with CONFIG_NUMA=y.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

Hi all,

On Wed, 25 Jul 2012 09:35:03 +0200 Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Wed, Jul 25, 2012 at 09:10:44AM +0200, Ingo Molnar wrote:
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Today's linux-next merge of the akpm tree got a conflict in 
> > > mm/migrate.c between the tip tree and commit "mm: memcg: fix 
> > > compaction/migration failing due to memcg limits" from the 
> > > akpm tree.
> > > 
> > > The commit 4783af477d3d ("mm: Migrate misplaced page") was 
> > > removed (among several others) from the tip tree since 
> > > yesterday (and thus linux-next) so the above akpm tree patch 
> > > no longer applies.
> > > 
> > > I have dropped this patch form the akpm tree (and the following patches
> > > as well:
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> > > mm: memcg: push down PageSwapCache check into uncharge entry functions
> > > mm: memcg: only check for PageSwapCache when uncharging anon
> > > mm: memcg: remove unneeded shmem charge type
> > > mm: memcg: remove needless !mm fixup to init_mm when charging
> > > )
> > > 
> > > Hopefully this doesn't cause other problems.  I guess that 
> > > they will need rebasing depending on what gets merged via the 
> > > tip tree.
> > 
> > Andrew, sorry about this last minute fallout: I felt that 
> > sched/numa was still not fully cooked and did not want to hold 
> > up the rest of the scheduler tree on that - nor did I want to 
> > send an uncooked tree to Linus.
> > 
> > PeterZ posted another series of sched/numa patches two days ago 
> > - once that is ready (probably after the merge window) it will 
> > all reappear again, in a slightly different form. I could stick 
> > the mm/ bits into a separate tree to make it easier for you.
> 
> As this is unlikely to reappear in this merge window, the conflict
> resolution is quite simple.  All that's needed is remove the 3 hunks
> from my patch that converted a user in Peter's patch to a new API.  I
> can resend the series if needed, but it's probably easier to just
> remove the hunks against mm/migrate.c::migrate_misplaced_page():

OK, so I have readded those patches to linux-next today with the
appropriate hunks removed.  Except for
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
which only touched the part of the file that no longer exists.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in
arch/x86/syscalls/syscall_64.tbl and arch/x86/syscalls/syscall_32.tbl
between commit a2dae61eb839 ("sched/numa: Introduce sys_numa_{t,m}bind()")
from the tip tree and commit "syscalls, x86: add __NR_kcmp syscall"
from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/syscalls/syscall_32.tbl
index 38954c5,7a35a6e..0000000
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@@ -355,5 -355,4 +355,6 @@@
  346	i386	setns			sys_setns
  347	i386	process_vm_readv	sys_process_vm_readv		compat_sys_process_vm_readv
  348	i386	process_vm_writev	sys_process_vm_writev		compat_sys_process_vm_writev
 -349	i386	kcmp			sys_kcmp
 +349	i386	numa_mbind		sys_numa_mbind			compat_sys_numa_mbind
 +350	i386	numa_tbind		sys_numa_tbind			compat_sys_numa_tbind
++351	i386	kcmp			sys_kcmp
diff --cc arch/x86/syscalls/syscall_64.tbl
index 63c5285,f1dd014..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -318,8 -318,7 +318,9 @@@
  309	common	getcpu			sys_getcpu
  310	64	process_vm_readv	sys_process_vm_readv
  311	64	process_vm_writev	sys_process_vm_writev
 -312	64	kcmp			sys_kcmp
 +312	64	numa_mbind		sys_numa_mbind
 +313	64	numa_tbind		sys_numa_tbind
++314	64	kcmp			sys_kcmp
  #
  # x32-specific system call numbers start at 512 to avoid cache impact
  # for native 64-bit operation.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in kernel/fork.c
between commit 0ea86208345b ("sched, mm: Rework sched_{fork,exec} node
assignment") from the tip tree and commit "task_work_add: generic
process-context callbacks" from the akpm tree.

Context changes.  I fixed it up (I think - see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/fork.c
index 5642958,b33046e..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1419,6 -1420,8 +1419,7 @@@ static struct task_struct *copy_process
  	 * We dont wake it up yet.
  	 */
  	p->group_leader = p;
 -	INIT_LIST_HEAD(&p->thread_group);
+ 	INIT_HLIST_HEAD(&p->task_works);
  
  	/* Now that the task is set up, run cgroup callbacks if
  	 * necessary. We need to run them before the task is visible

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/trampoline.c between commit c9b77ccb52a5 ("x86, realmode:
Move ACPI wakeup to unified realmode code") from the tip tree and commit
"x86: print physical addresses consistently with other parts of kernel"
from the akpm tree.

The former removed (or moved) the code modified by the latter and removed
the file, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in  between
commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
percpu_xxx funcs" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/mm/tlb.c
index 125bcad,e931db0..0000000
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@@ -61,13 -61,11 +61,13 @@@ static DEFINE_PER_CPU_READ_MOSTLY(int, 
   */
  void leave_mm(int cpu)
  {
- 	struct mm_struct *active_mm = percpu_read(cpu_tlbstate.active_mm);
- 	if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
++	struct mm_struct *active_mm = __this_cpu_read(cpu_tlbstate.active_mm);
+ 	if (__this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
  		BUG();
 -	cpumask_clear_cpu(cpu,
 -			  mm_cpumask(__this_cpu_read(cpu_tlbstate.active_mm)));
 -	load_cr3(swapper_pg_dir);
 +	if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
 +		cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
 +		load_cr3(swapper_pg_dir);
 +	}
  }
  EXPORT_SYMBOL_GPL(leave_mm);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Alex Shi]

On 03/26/2012 12:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in  between
> commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
> needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
> percpu_xxx funcs" from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks!

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/Kconfig between commit da4e3302949f ("x86/geode/net5501: Add
platform driver for Soekris Engineering net5501") from the tip tree and
commit "geos: platform driver for Geos and Geos2 single-board computers"
from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/Kconfig
index 97a7a56,a985f6b..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2151,12 -2151,13 +2151,19 @@@ config ALI
  
  	  Note: You have to set alix.force=1 for boards with Award BIOS.
  
 +config NET5501
 +	bool "Soekris Engineering net5501 System Support (LEDS, GPIO, etc)"
 +	select GPIOLIB
 +	---help---
 +	  This option enables system support for the Soekris Engineering net5501.
 +
+ config GEOS
+ 	bool "Traverse Technologies GEOS System Support (LEDS, GPIO, etc)"
+ 	select GPIOLIB
+ 	depends on DMI
+ 	---help---
+ 	  This option enables system support for the Traverse Technologies GEOS.
+ 
  endif # X86_32
  
  config AMD_NB

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/platform/olpc/olpc-xo15-sci.c between commit d1f42e314c9c
("x86/olpc/xo15/sci: Enable lid close wakeup control") from the tip tree
and commit "x86, olpc-xo15-sci: enable lid close wakeup control through
sysfs" from the akpm tree.

I assume that these were meant to be the same patch, so I dropped the one
from the akpm tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in arch/x86/Kconfig between commit 0bf6276392e9 ("x32: Warn and disable rather than error if binutils too old") from the tip tree and commit "ipc: provide generic compat versions of IPC syscalls" from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary,
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/Kconfig
index 3ccd69a,f50b52a..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2221,7 -2221,8 +2221,8 @@@ config X86_X3
  
  config COMPAT
  	def_bool y
 -	depends on IA32_EMULATION || X86_X32_ABI
 +	depends on IA32_EMULATION || X86_X32
+ 	select ARCH_WANT_OLD_COMPAT_IPC
  
  config COMPAT_FOR_U64_ALIGNMENT
  	def_bool COMPAT

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/nmi_selftest.c between commit f0ba662a6e06 ("x86:
Properly _init-annotate NMI selftest code") from the tip tree and commit
"x86: use this_cpu_xxx to replace percpu_xxx funcs" from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/kernel/nmi_selftest.c
index 2c39dcd,8aca005..0000000
--- a/arch/x86/kernel/nmi_selftest.c
+++ b/arch/x86/kernel/nmi_selftest.c
@@@ -12,7 -12,7 +12,8 @@@
  #include <linux/smp.h>
  #include <linux/cpumask.h>
  #include <linux/delay.h>
 +#include <linux/init.h>
+ #include <linux/percpu.h>
  
  #include <asm/apic.h>
  #include <asm/nmi.h>

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/syscalls/syscall_64.tbl between commit
arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
__NR_kcmp syscall" from the akpm tree.

I fixed it up (see below) but did not know if this call should be marked
"common".
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/syscalls/syscall_64.tbl
index 4aecc7e,ac3066f..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -304,50 -304,18 +304,51 @@@
  295	64	preadv			sys_preadv
  296	64	pwritev			sys_pwritev
  297	64	rt_tgsigqueueinfo	sys_rt_tgsigqueueinfo
 -298	64	perf_event_open		sys_perf_event_open
 +298	common	perf_event_open		sys_perf_event_open
  299	64	recvmmsg		sys_recvmmsg
 -300	64	fanotify_init		sys_fanotify_init
 -301	64	fanotify_mark		sys_fanotify_mark
 -302	64	prlimit64		sys_prlimit64
 -303	64	name_to_handle_at	sys_name_to_handle_at
 -304	64	open_by_handle_at	sys_open_by_handle_at
 -305	64	clock_adjtime		sys_clock_adjtime
 -306	64	syncfs			sys_syncfs
 +300	common	fanotify_init		sys_fanotify_init
 +301	common	fanotify_mark		sys_fanotify_mark
 +302	common	prlimit64		sys_prlimit64
 +303	common	name_to_handle_at	sys_name_to_handle_at
 +304	common	open_by_handle_at	sys_open_by_handle_at
 +305	common	clock_adjtime		sys_clock_adjtime
 +306	common	syncfs			sys_syncfs
  307	64	sendmmsg		sys_sendmmsg
 -308	64	setns			sys_setns
 -309	64	getcpu			sys_getcpu
 +308	common	setns			sys_setns
 +309	common	getcpu			sys_getcpu
  310	64	process_vm_readv	sys_process_vm_readv
  311	64	process_vm_writev	sys_process_vm_writev
+ 312	64	kcmp			sys_kcmp
 +#
 +# x32-specific system call numbers start at 512 to avoid cache impact
 +# for native 64-bit operation.
 +#
 +512	x32	rt_sigaction		sys32_rt_sigaction
 +513	x32	rt_sigreturn		stub_x32_rt_sigreturn
 +514	x32	ioctl			compat_sys_ioctl
 +515	x32	readv			compat_sys_readv
 +516	x32	writev			compat_sys_writev
 +517	x32	recvfrom		compat_sys_recvfrom
 +518	x32	sendmsg			compat_sys_sendmsg
 +519	x32	recvmsg			compat_sys_recvmsg
 +520	x32	execve			stub_x32_execve
 +521	x32	times			compat_sys_times
 +522	x32	rt_sigpending		sys32_rt_sigpending
 +523	x32	rt_sigtimedwait		compat_sys_rt_sigtimedwait
 +524	x32	rt_sigqueueinfo		sys32_rt_sigqueueinfo
 +525	x32	sigaltstack		stub_x32_sigaltstack
 +526	x32	timer_create		compat_sys_timer_create
 +527	x32	mq_notify		compat_sys_mq_notify
 +528	x32	kexec_load		compat_sys_kexec_load
 +529	x32	waitid			compat_sys_waitid
 +530	x32	set_robust_list		compat_sys_set_robust_list
 +531	x32	get_robust_list		compat_sys_get_robust_list
 +532	x32	vmsplice		compat_sys_vmsplice
 +533	x32	move_pages		compat_sys_move_pages
 +534	x32	preadv			compat_sys_preadv64
 +535	x32	pwritev			compat_sys_pwritev64
 +536	x32	rt_tgsigqueueinfo	compat_sys_rt_tgsigqueueinfo
 +537	x32	recvmmsg		compat_sys_recvmmsg
 +538	x32	sendmmsg		compat_sys_sendmmsg
 +539	x32	process_vm_readv	compat_sys_process_vm_readv
 +540	x32	process_vm_writev	compat_sys_process_vm_writev

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the tip tree

[Cyrill Gorcunov]

On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> __NR_kcmp syscall" from the akpm tree.
> 
> I fixed it up (see below) but did not know if this call should be marked
> "common".

Hi Stephen, letme fetch both trees to figure out what this new column means.
Will ping back shortly. Thanks!

	Cyrill

Re: linux-next: manual merge of the akpm tree with the tip tree

[H. Peter Anvin]

On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm tree got a conflict in
>> arch/x86/syscalls/syscall_64.tbl between commit
>> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
>> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
>> __NR_kcmp syscall" from the akpm tree.
>>
>> I fixed it up (see below) but did not know if this call should be marked
>> "common".
> 
> Hi Stephen, letme fetch both trees to figure out what this new column means.
> Will ping back shortly. Thanks!
> 
> 	Cyrill

Hi Cyrill,

"common" means the same entry point is used for x86-64 and x32.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Cyrill Gorcunov]

On Sun, Feb 26, 2012 at 10:02:11PM -0800, H. Peter Anvin wrote:
> On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> > On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> Today's linux-next merge of the akpm tree got a conflict in
> >> arch/x86/syscalls/syscall_64.tbl between commit
> >> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> >> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> >> __NR_kcmp syscall" from the akpm tree.
> >>
> >> I fixed it up (see below) but did not know if this call should be marked
> >> "common".
> > 
> > Hi Stephen, letme fetch both trees to figure out what this new column means.
> > Will ping back shortly. Thanks!
> > 
> 
> Hi Cyrill,
> 
> "common" means the same entry point is used for x86-64 and x32.
> 

Ah, I see. Thanks for explanation, Peter! So it should be a "common" then.

	Cyrill

Re: linux-next: manual merge of the akpm tree with the tip tree

[H. Peter Anvin]

On 02/26/2012 09:53 PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in 
> arch/x86/syscalls/syscall_64.tbl between commit 
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to 
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls,
> x86: add __NR_kcmp syscall" from the akpm tree.
> 
> I fixed it up (see below) but did not know if this call should be
> marked "common".

It should be "common" (otherwise there would need to be an x32 variant
which would point to the compat version of the call, but in this case
even the i386 entry point goes straight to sys_kcmp.)

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi Peter,

On Sun, 26 Feb 2012 22:01:21 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> It should be "common" (otherwise there would need to be an x32 variant
> which would point to the compat version of the call, but in this case
> even the i386 entry point goes straight to sys_kcmp.)

Thanks, I will fix up the merge resolution tomorrow.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/Kconfig between commit 5fd92e65a68b ("x32: Allow x32 to be
configured") from the tip tree and commit "ipc: provide generic compat
versions of IPC syscalls" from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/Kconfig
index 14b78d7,6f6807d..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2206,22 -2206,10 +2206,23 @@@ config IA32_AOU
  	---help---
  	  Support old a.out binaries in the 32bit emulation.
  
 +config X86_X32_ABI
 +	bool "x32 ABI for 64-bit mode (EXPERIMENTAL)"
 +	depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN
 +	---help---
 +	  Include code to run binaries for the x32 native 32-bit ABI
 +	  for 64-bit processors.  An x32 process gets access to the
 +	  full 64-bit register file and wide data path while leaving
 +	  pointers at 32 bits for smaller memory footprint.
 +
 +	  You will need a recent binutils (2.22 or later) with
 +	  elf32_x86_64 support enabled to compile a kernel with this
 +	  option set.
 +
  config COMPAT
  	def_bool y
 -	depends on IA32_EMULATION
 +	depends on IA32_EMULATION || X86_X32_ABI
+ 	select ARCH_WANT_OLD_COMPAT_IPC
  
  config COMPAT_FOR_U64_ALIGNMENT
  	def_bool COMPAT

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commits 8546c008924d ("i387: Uninline
the generic FP helpers that we expose to kernel modules") and
1361b83a13d4 ("i387: Split up <asm/i387.h> into exported and internal
interfaces") from the tip tree and commit
"percpu-remove-percpu_xxx-functions-fix" from the akpm tree.

I applied the appropriate part of the latter patch to
arch/x86/include/asm/fpu-internal.h and arch/x86/kernel/i387.c (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 5caaf43..e9801b4 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -290,14 +290,14 @@ static inline int __thread_has_fpu(struct task_struct *tsk)
 static inline void __thread_clear_has_fpu(struct task_struct *tsk)
 {
 	tsk->thread.fpu.has_fpu = 0;
-	percpu_write(fpu_owner_task, NULL);
+	__this_cpu_write(fpu_owner_task, NULL);
 }
 
 /* Must be paired with a 'clts' before! */
 static inline void __thread_set_has_fpu(struct task_struct *tsk)
 {
 	tsk->thread.fpu.has_fpu = 1;
-	percpu_write(fpu_owner_task, tsk);
+	__this_cpu_write(fpu_owner_task, tsk);
 }
 
 /*
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7734bcb..32c3972 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -88,7 +88,7 @@ void kernel_fpu_begin(void)
 		__thread_clear_has_fpu(me);
 		/* We do 'stts()' in kernel_fpu_end() */
 	} else {
-		percpu_write(fpu_owner_task, NULL);
+		__this_cpu_write(fpu_owner_task, NULL);
 		clts();
 	}
 }

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/irq/manage.c between commit b4bc724e82e8 ("genirq: Handle pending
irqs in irq_startup()") from the tip tree and commit "irqs: fix handling
of pending IRQs at request time" from the akpm tree.

It looks like the former is a superset of the latter, so I dropped the
latter.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commit 1361b83a13d4 ("i387: Split up
<asm/i387.h> into exported and internal interfaces") from the tip tree
and commit "x86-change-percpu_read_stable-to-this_cpu_read_stable-fix"
from the akpm tree.

The former commit moved the code to arch/x86/include/asm/fpu-internal.h,
so I applied the patch there (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 4fa8815..5caaf43 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -344,7 +344,7 @@ typedef struct { int preload; } fpu_switch_t;
  */
 static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
 {
-	return new == percpu_read_stable(fpu_owner_task) &&
+	return new == this_cpu_read_stable(fpu_owner_task) &&
 		cpu == new->thread.fpu.last_cpu;
 }
 

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/Makefile between commit 029632fbb7b7 ("sched: Make separate
sched*.c translation units") from the tip tree and commit f7243fa71a4c
("brlocks/lglocks: clean up code") from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/Makefile
index 4363a41,d173c0c..0000000
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -9,8 -9,9 +9,8 @@@ obj-y     = fork.o exec_domain.o panic.
  	    rcupdate.o extable.o params.o posix-timers.o \
  	    kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
  	    hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
 -	    notifier.o ksysfs.o sched_clock.o cred.o \
 -	    async.o range.o
 -obj-y += groups.o lglock.o
 +	    notifier.o ksysfs.o cred.o \
- 	    async.o range.o groups.o
++	    async.o range.o groups.o lglock.o
  
  ifdef CONFIG_FUNCTION_TRACER
  # Do not trace debug files and internal ftrace files

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in
drivers/iommu/dmar.c and include/linux/dmar.h between commit 318fe7df9d84
("iommu: Move IOMMU specific code to intel-iommu.c") from the tip tree
and commit 432fb2751763 ("When do pci remove/rescan on system that have
more iommus, got") from the akpm tree.

The former moved that code the the latter cares about to another files.
I have dropped this patch from the akpm tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]