linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2013-11-08  7:48 Stephen Rothwell
  2013-11-08 18:58 ` Josh Triplett
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2013-11-08  7:48 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Josh Triplett

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/Makefile between commits 60fc28746a7b ("locking: Move the spinlock
code to kernel/locking/") and cd4d241d57c9 ("locking: Move the lglocks
code to kernel/locking/") from the tip tree and commit f5639052d567
("lglock: map to spinlock when !CONFIG_SMP") from the akpm-current tree.

I fixed it up (dropping the kernel/Makefile section of the akpm-current
commit and adding the below patch) and can carry the fix as necessary (no
action is required).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 8 Nov 2013 18:45:25 +1100
Subject: [PATCH] lglock: fixup for code movement

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/locking/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index baab8e5e7f66..bb3c65930a20 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -1,5 +1,5 @@
 
-obj-y += mutex.o semaphore.o rwsem.o lglock.o
+obj-y += mutex.o semaphore.o rwsem.o
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_lockdep.o = -pg
@@ -8,6 +8,7 @@ CFLAGS_REMOVE_mutex-debug.o = -pg
 CFLAGS_REMOVE_rtmutex-debug.o = -pg
 endif
 
+obj-$(CONFIG_SMP) += lglock.o
 obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
 obj-$(CONFIG_LOCKDEP) += lockdep.o
 ifeq ($(CONFIG_PROC_FS),y)
-- 
1.8.4.2

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

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

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2013-11-08  7:48 linux-next: manual merge of the akpm-current tree with the tip tree Stephen Rothwell
@ 2013-11-08 18:58 ` Josh Triplett
  2013-11-08 23:20   ` Stephen Rothwell
  0 siblings, 1 reply; 112+ messages in thread
From: Josh Triplett @ 2013-11-08 18:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Fri, Nov 08, 2013 at 06:48:05PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/Makefile between commits 60fc28746a7b ("locking: Move the spinlock
> code to kernel/locking/") and cd4d241d57c9 ("locking: Move the lglocks
> code to kernel/locking/") from the tip tree and commit f5639052d567
> ("lglock: map to spinlock when !CONFIG_SMP") from the akpm-current tree.
> 
> I fixed it up (dropping the kernel/Makefile section of the akpm-current
> commit and adding the below patch) and can carry the fix as necessary (no
> action is required).

Won't splitting the Makefile change into a separate commit break
bisection, in particular if you have the changes adding inlines but you
also compile in lglock.o?  Shouldn't this be squashed into the merge
itself, keeping the kernel/Makefile section of my original patch?

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 8 Nov 2013 18:45:25 +1100
> Subject: [PATCH] lglock: fixup for code movement
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  kernel/locking/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
> index baab8e5e7f66..bb3c65930a20 100644
> --- a/kernel/locking/Makefile
> +++ b/kernel/locking/Makefile
> @@ -1,5 +1,5 @@
>  
> -obj-y += mutex.o semaphore.o rwsem.o lglock.o
> +obj-y += mutex.o semaphore.o rwsem.o
>  
>  ifdef CONFIG_FUNCTION_TRACER
>  CFLAGS_REMOVE_lockdep.o = -pg
> @@ -8,6 +8,7 @@ CFLAGS_REMOVE_mutex-debug.o = -pg
>  CFLAGS_REMOVE_rtmutex-debug.o = -pg
>  endif
>  
> +obj-$(CONFIG_SMP) += lglock.o
>  obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
>  obj-$(CONFIG_LOCKDEP) += lockdep.o
>  ifeq ($(CONFIG_PROC_FS),y)
> -- 
> 1.8.4.2
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au



^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2013-11-08 18:58 ` Josh Triplett
@ 2013-11-08 23:20   ` Stephen Rothwell
  2013-11-09  0:19     ` Josh Triplett
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2013-11-08 23:20 UTC (permalink / raw)
  To: Josh Triplett
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

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

Hi Josh,

On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett <josh@joshtriplett.org> wrote:
>
> Won't splitting the Makefile change into a separate commit break
> bisection, in particular if you have the changes adding inlines but you
> also compile in lglock.o?  Shouldn't this be squashed into the merge
> itself, keeping the kernel/Makefile section of my original patch?

Actually it is not a problem because that fix patch was applied to the
merge commit between the part of Andrew's tree that depends only on
Linus' tree and the rest of linux-next.  So each side of the merge is ok
and the merge commit itself fixes up the conflict.

I just split it this way for my work flow purposes.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2013-11-08 23:20   ` Stephen Rothwell
@ 2013-11-09  0:19     ` Josh Triplett
  0 siblings, 0 replies; 112+ messages in thread
From: Josh Triplett @ 2013-11-09  0:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Sat, Nov 09, 2013 at 10:20:58AM +1100, Stephen Rothwell wrote:
> Hi Josh,
> 
> On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett <josh@joshtriplett.org> wrote:
> >
> > Won't splitting the Makefile change into a separate commit break
> > bisection, in particular if you have the changes adding inlines but you
> > also compile in lglock.o?  Shouldn't this be squashed into the merge
> > itself, keeping the kernel/Makefile section of my original patch?
> 
> Actually it is not a problem because that fix patch was applied to the
> merge commit between the part of Andrew's tree that depends only on
> Linus' tree and the rest of linux-next.  So each side of the merge is ok
> and the merge commit itself fixes up the conflict.
> 
> I just split it this way for my work flow purposes.

Ah, I see.  That wasn't obvious to me from your previous mail explaining
your fix. :)

- Josh Triplett

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2022-02-16  5:38 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2022-02-16  5:38 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Huang, Ying, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  Documentation/admin-guide/sysctl/kernel.rst

between commit:

  3624ba7b5e2a ("sched/numa-balancing: Move some document to make it consistent with the code")

from the tip tree and commit:

  2dc52f4f86f9 ("NUMA balancing: optimize page placement for memory tiering system")

from the akpm-current 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 Documentation/admin-guide/sysctl/kernel.rst
index 8551aeca1574,59c3b4ce37cd..000000000000
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@@ -609,8 -616,56 +616,14 @@@ being accessed should be migrated to a 
  The unmapping of pages and trapping faults incur additional overhead that
  ideally is offset by improved memory locality but there is no universal
  guarantee. If the target workload is already bound to NUMA nodes then this
 -feature should be disabled. Otherwise, if the system overhead from the
 -feature is too high then the rate the kernel samples for NUMA hinting
 -faults may be controlled by the `numa_balancing_scan_period_min_ms,
 -numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
 -numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls.
 +feature should be disabled.
  
+ Or NUMA_BALANCING_MEMORY_TIERING to optimize page placement among
+ different types of memory (represented as different NUMA nodes) to
+ place the hot pages in the fast memory.  This is implemented based on
+ unmapping and page fault too.
 -
 -numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb
 -===============================================================================================================================
 -
 -
 -Automatic NUMA balancing scans tasks address space and unmaps pages to
 -detect if pages are properly placed or if the data should be migrated to a
 -memory node local to where the task is running.  Every "scan delay" the task
 -scans the next "scan size" number of pages in its address space. When the
 -end of the address space is reached the scanner restarts from the beginning.
 -
 -In combination, the "scan delay" and "scan size" determine the scan rate.
 -When "scan delay" decreases, the scan rate increases.  The scan delay and
 -hence the scan rate of every task is adaptive and depends on historical
 -behaviour. If pages are properly placed then the scan delay increases,
 -otherwise the scan delay decreases.  The "scan size" is not adaptive but
 -the higher the "scan size", the higher the scan rate.
 -
 -Higher scan rates incur higher system overhead as page faults must be
 -trapped and potentially data must be migrated. However, the higher the scan
 -rate, the more quickly a tasks memory is migrated to a local node if the
 -workload pattern changes and minimises performance impact due to remote
 -memory accesses. These sysctls control the thresholds for scan delays and
 -the number of pages scanned.
 -
 -``numa_balancing_scan_period_min_ms`` is the minimum time in milliseconds to
 -scan a tasks virtual memory. It effectively controls the maximum scanning
 -rate for each task.
 -
 -``numa_balancing_scan_delay_ms`` is the starting "scan delay" used for a task
 -when it initially forks.
 -
 -``numa_balancing_scan_period_max_ms`` is the maximum time in milliseconds to
 -scan a tasks virtual memory. It effectively controls the minimum scanning
 -rate for each task.
 -
 -``numa_balancing_scan_size_mb`` is how many megabytes worth of pages are
 -scanned for a given scan.
+ 
+ 
  oops_all_cpu_backtrace
  ======================
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2021-10-07  6:27 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2021-10-07  6:27 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Nicholas Piggin

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

Hi all,

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

  include/linux/sched/mm.h
  kernel/sched/core.c

between commit:

  8d491de6edc2 ("sched: Move mmdrop to RCU on RT")

from the tip tree and commits:

  5a21ba83ddb2 ("lazy tlb: introduce lazy mm refcount helper functions")
  ade2ef2cb563 ("lazy tlb: allow lazy tlb mm refcounting to be configurable")

from the akpm-current tree.

I don't know if my merging of both these makes sense, but guidance
is welcome.

I fixed it up (see below, and used the latter version of kernel/sched/core.c
) 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 include/linux/sched/mm.h
index aca874d33fe6,fd6e4d14f477..000000000000
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@@ -49,35 -49,27 +49,56 @@@ static inline void mmdrop(struct mm_str
  		__mmdrop(mm);
  }
  
 +#ifdef CONFIG_PREEMPT_RT
 +/*
 + * RCU callback for delayed mm drop. Not strictly RCU, but call_rcu() is
 + * by far the least expensive way to do that.
 + */
 +static inline void __mmdrop_delayed(struct rcu_head *rhp)
 +{
 +	struct mm_struct *mm = container_of(rhp, struct mm_struct, delayed_drop);
 +
 +	__mmdrop(mm);
 +}
 +
 +/*
 + * Invoked from finish_task_switch(). Delegates the heavy lifting on RT
 + * kernels via RCU.
 + */
 +static inline void mmdrop_sched(struct mm_struct *mm)
 +{
 +	/* Provides a full memory barrier. See mmdrop() */
 +	if (atomic_dec_and_test(&mm->mm_count))
 +		call_rcu(&mm->delayed_drop, __mmdrop_delayed);
 +}
 +#else
 +static inline void mmdrop_sched(struct mm_struct *mm)
 +{
 +	mmdrop(mm);
 +}
 +#endif
 +
+ /* Helpers for lazy TLB mm refcounting */
+ static inline void mmgrab_lazy_tlb(struct mm_struct *mm)
+ {
+ 	if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_REFCOUNT))
+ 		mmgrab(mm);
+ }
+ 
+ static inline void mmdrop_lazy_tlb(struct mm_struct *mm)
+ {
+ 	if (IS_ENABLED(CONFIG_MMU_LAZY_TLB_REFCOUNT)) {
 -		mmdrop(mm);
++		mmdrop_sched(mm);
+ 	} else {
+ 		/*
+ 		 * mmdrop_lazy_tlb must provide a full memory barrier, see the
+ 		 * membarrier comment in finish_task_switch which relies on
+ 		 * this.
+ 		 */
+ 		smp_mb();
+ 	}
+ }
+ 
  /**
   * mmget() - Pin the address space associated with a &struct mm_struct.
   * @mm: The address space to pin.

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2021-03-22  6:12 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2021-03-22  6:12 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Oscar Salvador

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

Hi all,

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

  arch/x86/mm/init_64.c

between commit:

  d9f6e12fb0b7 ("x86: Fix various typos in comments")

from the tip tree and commit:

  68f7bf6e7e98 ("x86/vmemmap: drop handling of 4K unaligned vmemmap range")

from the akpm-current tree.

I fixed it up (the latter removed the comments fixed up by the former)
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 --]

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2020-12-11  8:56 Stephen Rothwell
@ 2020-12-11 12:47 ` Jason Gunthorpe
  0 siblings, 0 replies; 112+ messages in thread
From: Jason Gunthorpe @ 2020-12-11 12:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

On Fri, Dec 11, 2020 at 07:56:54PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/gup.c
> 
> between commit:
> 
>   2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")
> 
> from the tip tree and commit:
> 
>   1eb2fe862a51 ("mm/gup: combine put_compound_head() and unpin_user_page()")
> 
> from the akpm-current 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.

Looks OK

Thanks,
Jason
 



^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-12-11  8:56 Stephen Rothwell
  2020-12-11 12:47 ` Jason Gunthorpe
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2020-12-11  8:56 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Jason Gunthorpe, Jason Gunthorpe, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

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

  mm/gup.c

between commit:

  2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")

from the tip tree and commit:

  1eb2fe862a51 ("mm/gup: combine put_compound_head() and unpin_user_page()")

from the akpm-current 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 mm/gup.c
index 44b0c6b89602,b3d852b4a60c..000000000000
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -2062,29 -1977,62 +1977,6 @@@ EXPORT_SYMBOL(get_user_pages_unlocked)
   * This code is based heavily on the PowerPC implementation by Nick Piggin.
   */
  #ifdef CONFIG_HAVE_FAST_GUP
 -#ifdef CONFIG_GUP_GET_PTE_LOW_HIGH
--
- static void put_compound_head(struct page *page, int refs, unsigned int flags)
 -/*
 - * WARNING: only to be used in the get_user_pages_fast() implementation.
 - *
 - * With get_user_pages_fast(), we walk down the pagetables without taking any
 - * locks.  For this we would like to load the pointers atomically, but sometimes
 - * that is not possible (e.g. without expensive cmpxchg8b on x86_32 PAE).  What
 - * we do have is the guarantee that a PTE will only either go from not present
 - * to present, or present to not present or both -- it will not switch to a
 - * completely different present page without a TLB flush in between; something
 - * that we are blocking by holding interrupts off.
 - *
 - * Setting ptes from not present to present goes:
 - *
 - *   ptep->pte_high = h;
 - *   smp_wmb();
 - *   ptep->pte_low = l;
 - *
 - * And present to not present goes:
 - *
 - *   ptep->pte_low = 0;
 - *   smp_wmb();
 - *   ptep->pte_high = 0;
 - *
 - * We must ensure here that the load of pte_low sees 'l' IFF pte_high sees 'h'.
 - * We load pte_high *after* loading pte_low, which ensures we don't see an older
 - * value of pte_high.  *Then* we recheck pte_low, which ensures that we haven't
 - * picked up a changed pte high. We might have gotten rubbish values from
 - * pte_low and pte_high, but we are guaranteed that pte_low will not have the
 - * present bit set *unless* it is 'l'. Because get_user_pages_fast() only
 - * operates on present ptes we're safe.
 - */
 -static inline pte_t gup_get_pte(pte_t *ptep)
--{
- 	if (flags & FOLL_PIN) {
- 		mod_node_page_state(page_pgdat(page), NR_FOLL_PIN_RELEASED,
- 				    refs);
 -	pte_t pte;
--
- 		if (hpage_pincount_available(page))
- 			hpage_pincount_sub(page, refs);
- 		else
- 			refs *= GUP_PIN_COUNTING_BIAS;
- 	}
 -	do {
 -		pte.pte_low = ptep->pte_low;
 -		smp_rmb();
 -		pte.pte_high = ptep->pte_high;
 -		smp_rmb();
 -	} while (unlikely(pte.pte_low != ptep->pte_low));
--
- 	VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
- 	/*
- 	 * Calling put_page() for each ref is unnecessarily slow. Only the last
- 	 * ref needs a put_page().
- 	 */
- 	if (refs > 1)
- 		page_ref_sub(page, refs - 1);
- 	put_page(page);
 -	return pte;
 -}
 -#else /* CONFIG_GUP_GET_PTE_LOW_HIGH */
 -/*
 - * We require that the PTE can be read atomically.
 - */
 -static inline pte_t gup_get_pte(pte_t *ptep)
 -{
 -	return ptep_get(ptep);
--}
 -#endif /* CONFIG_GUP_GET_PTE_LOW_HIGH */
--
  static void __maybe_unused undo_dev_pagemap(int *nr, int nr_start,
  					    unsigned int flags,
  					    struct page **pages)

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2020-11-27 11:54 ` Andy Shevchenko
@ 2020-11-30  9:27   ` Thomas Gleixner
  0 siblings, 0 replies; 112+ messages in thread
From: Thomas Gleixner @ 2020-11-30  9:27 UTC (permalink / raw)
  To: Andy Shevchenko, Stephen Rothwell
  Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

On Fri, Nov 27 2020 at 13:54, Andy Shevchenko wrote:
>> 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.
>
> Thanks, from my perspective looks good, dunno if scheduler part is okay.

The final outcome in -next looks correct.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2020-11-27  7:39 Stephen Rothwell
@ 2020-11-27 11:54 ` Andy Shevchenko
  2020-11-30  9:27   ` Thomas Gleixner
  0 siblings, 1 reply; 112+ messages in thread
From: Andy Shevchenko @ 2020-11-27 11:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux Kernel Mailing List,
	Linux Next Mailing List

On Fri, Nov 27, 2020 at 06:39:24PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/kernel.h
> 
> between commit:
> 
>   74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT")
> 
> from the tip tree and commit:
> 
>   761ace49e56f ("kernel.h: Split out mathematical helpers")
> 
> from the akpm-current 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.

Thanks, from my perspective looks good, dunno if scheduler part is okay.

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc include/linux/kernel.h
> index dbf6018fc312,f97ab3283a8b..000000000000
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@@ -272,48 -145,13 +159,6 @@@ extern void __cant_migrate(const char *
>   
>   #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
>   
> - /**
> -  * abs - return absolute value of an argument
> -  * @x: the value.  If it is unsigned type, it is converted to signed type first.
> -  *     char is treated as if it was signed (regardless of whether it really is)
> -  *     but the macro's return type is preserved as char.
> -  *
> -  * Return: an absolute value of x.
> -  */
> - #define abs(x)	__abs_choose_expr(x, long long,				\
> - 		__abs_choose_expr(x, long,				\
> - 		__abs_choose_expr(x, int,				\
> - 		__abs_choose_expr(x, short,				\
> - 		__abs_choose_expr(x, char,				\
> - 		__builtin_choose_expr(					\
> - 			__builtin_types_compatible_p(typeof(x), char),	\
> - 			(char)({ signed char __x = (x); __x<0?-__x:__x; }), \
> - 			((void)0)))))))
> - 
> - #define __abs_choose_expr(x, type, other) __builtin_choose_expr(	\
> - 	__builtin_types_compatible_p(typeof(x),   signed type) ||	\
> - 	__builtin_types_compatible_p(typeof(x), unsigned type),		\
> - 	({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
> - 
> - /**
> -  * reciprocal_scale - "scale" a value into range [0, ep_ro)
> -  * @val: value
> -  * @ep_ro: right open interval endpoint
> -  *
> -  * Perform a "reciprocal multiplication" in order to "scale" a value into
> -  * range [0, @ep_ro), where the upper interval endpoint is right-open.
> -  * This is useful, e.g. for accessing a index of an array containing
> -  * @ep_ro elements, for example. Think of it as sort of modulus, only that
> -  * the result isn't that of modulo. ;) Note that if initial input is a
> -  * small value, then result will return 0.
> -  *
> -  * Return: a result based on @val in interval [0, @ep_ro).
> -  */
> - static inline u32 reciprocal_scale(u32 val, u32 ep_ro)
> - {
> - 	return (u32)(((u64) val * ep_ro) >> 32);
> - }
>  -#ifndef CONFIG_PREEMPT_RT
>  -# define cant_migrate()		cant_sleep()
>  -#else
>  -  /* Placeholder for now */
>  -# define cant_migrate()		do { } while (0)
>  -#endif
> --
>   #if defined(CONFIG_MMU) && \
>   	(defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP))
>   #define might_fault() __might_fault(__FILE__, __LINE__)



-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-11-27  7:48 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-11-27  7:48 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Matthew Wilcox (Oracle)

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

Hi all,

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

  mm/highmem.c

between commits:

  298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*")
  5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct")

from the tip tree and commit:

  72d22a0d0e86 ("mm: support THPs in zero_user_segments")

from the akpm-current 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 mm/highmem.c
index 83f9660f168f,e2da8c9770e9..000000000000
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@@ -358,260 -367,68 +358,319 @@@ void kunmap_high(struct page *page
  	if (need_wakeup)
  		wake_up(pkmap_map_wait);
  }
 -
  EXPORT_SYMBOL(kunmap_high);
+ 
+ #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ void zero_user_segments(struct page *page, unsigned start1, unsigned end1,
+ 		unsigned start2, unsigned end2)
+ {
+ 	unsigned int i;
+ 
+ 	BUG_ON(end1 > page_size(page) || end2 > page_size(page));
+ 
+ 	for (i = 0; i < compound_nr(page); i++) {
+ 		void *kaddr;
+ 		unsigned this_end;
+ 
+ 		if (end1 == 0 && start2 >= PAGE_SIZE) {
+ 			start2 -= PAGE_SIZE;
+ 			end2 -= PAGE_SIZE;
+ 			continue;
+ 		}
+ 
+ 		if (start1 >= PAGE_SIZE) {
+ 			start1 -= PAGE_SIZE;
+ 			end1 -= PAGE_SIZE;
+ 			if (start2) {
+ 				start2 -= PAGE_SIZE;
+ 				end2 -= PAGE_SIZE;
+ 			}
+ 			continue;
+ 		}
+ 
+ 		kaddr = kmap_atomic(page + i);
+ 
+ 		this_end = min_t(unsigned, end1, PAGE_SIZE);
+ 		if (end1 > start1)
+ 			memset(kaddr + start1, 0, this_end - start1);
+ 		end1 -= this_end;
+ 		start1 = 0;
+ 
+ 		if (start2 >= PAGE_SIZE) {
+ 			start2 -= PAGE_SIZE;
+ 			end2 -= PAGE_SIZE;
+ 		} else {
+ 			this_end = min_t(unsigned, end2, PAGE_SIZE);
+ 			if (end2 > start2)
+ 				memset(kaddr + start2, 0, this_end - start2);
+ 			end2 -= this_end;
+ 			start2 = 0;
+ 		}
+ 
+ 		kunmap_atomic(kaddr);
+ 		flush_dcache_page(page + i);
+ 
+ 		if (!end1 && !end2)
+ 			break;
+ 	}
+ 
+ 	BUG_ON((start1 | start2 | end1 | end2) != 0);
+ }
+ EXPORT_SYMBOL(zero_user_segments);
+ #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 -#endif	/* CONFIG_HIGHMEM */
 +#endif /* CONFIG_HIGHMEM */
 +
 +#ifdef CONFIG_KMAP_LOCAL
 +
 +#include <asm/kmap_size.h>
 +
 +/*
 + * With DEBUG_KMAP_LOCAL the stack depth is doubled and every second
 + * slot is unused which acts as a guard page
 + */
 +#ifdef CONFIG_DEBUG_KMAP_LOCAL
 +# define KM_INCR	2
 +#else
 +# define KM_INCR	1
 +#endif
 +
 +static inline int kmap_local_idx_push(void)
 +{
 +	WARN_ON_ONCE(in_irq() && !irqs_disabled());
 +	current->kmap_ctrl.idx += KM_INCR;
 +	BUG_ON(current->kmap_ctrl.idx >= KM_MAX_IDX);
 +	return current->kmap_ctrl.idx - 1;
 +}
 +
 +static inline int kmap_local_idx(void)
 +{
 +	return current->kmap_ctrl.idx - 1;
 +}
 +
 +static inline void kmap_local_idx_pop(void)
 +{
 +	current->kmap_ctrl.idx -= KM_INCR;
 +	BUG_ON(current->kmap_ctrl.idx < 0);
 +}
 +
 +#ifndef arch_kmap_local_post_map
 +# define arch_kmap_local_post_map(vaddr, pteval)	do { } while (0)
 +#endif
 +
 +#ifndef arch_kmap_local_pre_unmap
 +# define arch_kmap_local_pre_unmap(vaddr)		do { } while (0)
 +#endif
 +
 +#ifndef arch_kmap_local_post_unmap
 +# define arch_kmap_local_post_unmap(vaddr)		do { } while (0)
 +#endif
 +
 +#ifndef arch_kmap_local_map_idx
 +#define arch_kmap_local_map_idx(idx, pfn)	kmap_local_calc_idx(idx)
 +#endif
 +
 +#ifndef arch_kmap_local_unmap_idx
 +#define arch_kmap_local_unmap_idx(idx, vaddr)	kmap_local_calc_idx(idx)
 +#endif
 +
 +#ifndef arch_kmap_local_high_get
 +static inline void *arch_kmap_local_high_get(struct page *page)
 +{
 +	return NULL;
 +}
 +#endif
 +
 +/* Unmap a local mapping which was obtained by kmap_high_get() */
 +static inline bool kmap_high_unmap_local(unsigned long vaddr)
 +{
 +#ifdef ARCH_NEEDS_KMAP_HIGH_GET
 +	if (vaddr >= PKMAP_ADDR(0) && vaddr < PKMAP_ADDR(LAST_PKMAP)) {
 +		kunmap_high(pte_page(pkmap_page_table[PKMAP_NR(vaddr)]));
 +		return true;
 +	}
 +#endif
 +	return false;
 +}
 +
 +static inline int kmap_local_calc_idx(int idx)
 +{
 +	return idx + KM_MAX_IDX * smp_processor_id();
 +}
 +
 +static pte_t *__kmap_pte;
 +
 +static pte_t *kmap_get_pte(void)
 +{
 +	if (!__kmap_pte)
 +		__kmap_pte = virt_to_kpte(__fix_to_virt(FIX_KMAP_BEGIN));
 +	return __kmap_pte;
 +}
 +
 +void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot)
 +{
 +	pte_t pteval, *kmap_pte = kmap_get_pte();
 +	unsigned long vaddr;
 +	int idx;
 +
 +	/*
 +	 * Disable migration so resulting virtual address is stable
 +	 * accross preemption.
 +	 */
 +	migrate_disable();
 +	preempt_disable();
 +	idx = arch_kmap_local_map_idx(kmap_local_idx_push(), pfn);
 +	vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
 +	BUG_ON(!pte_none(*(kmap_pte - idx)));
 +	pteval = pfn_pte(pfn, prot);
 +	set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval);
 +	arch_kmap_local_post_map(vaddr, pteval);
 +	current->kmap_ctrl.pteval[kmap_local_idx()] = pteval;
 +	preempt_enable();
 +
 +	return (void *)vaddr;
 +}
 +EXPORT_SYMBOL_GPL(__kmap_local_pfn_prot);
 +
 +void *__kmap_local_page_prot(struct page *page, pgprot_t prot)
 +{
 +	void *kmap;
 +
 +	/*
 +	 * To broaden the usage of the actual kmap_local() machinery always map
 +	 * pages when debugging is enabled and the architecture has no problems
 +	 * with alias mappings.
 +	 */
 +	if (!IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) && !PageHighMem(page))
 +		return page_address(page);
 +
 +	/* Try kmap_high_get() if architecture has it enabled */
 +	kmap = arch_kmap_local_high_get(page);
 +	if (kmap)
 +		return kmap;
 +
 +	return __kmap_local_pfn_prot(page_to_pfn(page), prot);
 +}
 +EXPORT_SYMBOL(__kmap_local_page_prot);
 +
 +void kunmap_local_indexed(void *vaddr)
 +{
 +	unsigned long addr = (unsigned long) vaddr & PAGE_MASK;
 +	pte_t *kmap_pte = kmap_get_pte();
 +	int idx;
 +
 +	if (addr < __fix_to_virt(FIX_KMAP_END) ||
 +	    addr > __fix_to_virt(FIX_KMAP_BEGIN)) {
 +		if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP)) {
 +			/* This _should_ never happen! See above. */
 +			WARN_ON_ONCE(1);
 +			return;
 +		}
 +		/*
 +		 * Handle mappings which were obtained by kmap_high_get()
 +		 * first as the virtual address of such mappings is below
 +		 * PAGE_OFFSET. Warn for all other addresses which are in
 +		 * the user space part of the virtual address space.
 +		 */
 +		if (!kmap_high_unmap_local(addr))
 +			WARN_ON_ONCE(addr < PAGE_OFFSET);
 +		return;
 +	}
 +
 +	preempt_disable();
 +	idx = arch_kmap_local_unmap_idx(kmap_local_idx(), addr);
 +	WARN_ON_ONCE(addr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
 +
 +	arch_kmap_local_pre_unmap(addr);
 +	pte_clear(&init_mm, addr, kmap_pte - idx);
 +	arch_kmap_local_post_unmap(addr);
 +	current->kmap_ctrl.pteval[kmap_local_idx()] = __pte(0);
 +	kmap_local_idx_pop();
 +	preempt_enable();
 +	migrate_enable();
 +}
 +EXPORT_SYMBOL(kunmap_local_indexed);
 +
 +/*
 + * Invoked before switch_to(). This is safe even when during or after
 + * clearing the maps an interrupt which needs a kmap_local happens because
 + * the task::kmap_ctrl.idx is not modified by the unmapping code so a
 + * nested kmap_local will use the next unused index and restore the index
 + * on unmap. The already cleared kmaps of the outgoing task are irrelevant
 + * because the interrupt context does not know about them. The same applies
 + * when scheduling back in for an interrupt which happens before the
 + * restore is complete.
 + */
 +void __kmap_local_sched_out(void)
 +{
 +	struct task_struct *tsk = current;
 +	pte_t *kmap_pte = kmap_get_pte();
 +	int i;
 +
 +	/* Clear kmaps */
 +	for (i = 0; i < tsk->kmap_ctrl.idx; i++) {
 +		pte_t pteval = tsk->kmap_ctrl.pteval[i];
 +		unsigned long addr;
 +		int idx;
 +
 +		/* With debug all even slots are unmapped and act as guard */
 +		if (IS_ENABLED(CONFIG_DEBUG_HIGHMEM) && !(i & 0x01)) {
 +			WARN_ON_ONCE(!pte_none(pteval));
 +			continue;
 +		}
 +		if (WARN_ON_ONCE(pte_none(pteval)))
 +			continue;
 +
 +		/*
 +		 * This is a horrible hack for XTENSA to calculate the
 +		 * coloured PTE index. Uses the PFN encoded into the pteval
 +		 * and the map index calculation because the actual mapped
 +		 * virtual address is not stored in task::kmap_ctrl.
 +		 * For any sane architecture this is optimized out.
 +		 */
 +		idx = arch_kmap_local_map_idx(i, pte_pfn(pteval));
 +
 +		addr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
 +		arch_kmap_local_pre_unmap(addr);
 +		pte_clear(&init_mm, addr, kmap_pte - idx);
 +		arch_kmap_local_post_unmap(addr);
 +	}
 +}
 +
 +void __kmap_local_sched_in(void)
 +{
 +	struct task_struct *tsk = current;
 +	pte_t *kmap_pte = kmap_get_pte();
 +	int i;
 +
 +	/* Restore kmaps */
 +	for (i = 0; i < tsk->kmap_ctrl.idx; i++) {
 +		pte_t pteval = tsk->kmap_ctrl.pteval[i];
 +		unsigned long addr;
 +		int idx;
 +
 +		/* With debug all even slots are unmapped and act as guard */
 +		if (IS_ENABLED(CONFIG_DEBUG_HIGHMEM) && !(i & 0x01)) {
 +			WARN_ON_ONCE(!pte_none(pteval));
 +			continue;
 +		}
 +		if (WARN_ON_ONCE(pte_none(pteval)))
 +			continue;
 +
 +		/* See comment in __kmap_local_sched_out() */
 +		idx = arch_kmap_local_map_idx(i, pte_pfn(pteval));
 +		addr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
 +		set_pte_at(&init_mm, addr, kmap_pte - idx, pteval);
 +		arch_kmap_local_post_map(addr, pteval);
 +	}
 +}
 +
 +void kmap_local_fork(struct task_struct *tsk)
 +{
 +	if (WARN_ON_ONCE(tsk->kmap_ctrl.idx))
 +		memset(&tsk->kmap_ctrl, 0, sizeof(tsk->kmap_ctrl));
 +}
 +
 +#endif
  
  #if defined(HASHED_PAGE_VIRTUAL)
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-11-27  7:39 Stephen Rothwell
  2020-11-27 11:54 ` Andy Shevchenko
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2020-11-27  7:39 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Andy Shevchenko, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  include/linux/kernel.h

between commit:

  74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT")

from the tip tree and commit:

  761ace49e56f ("kernel.h: Split out mathematical helpers")

from the akpm-current 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 include/linux/kernel.h
index dbf6018fc312,f97ab3283a8b..000000000000
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@@ -272,48 -145,13 +159,6 @@@ extern void __cant_migrate(const char *
  
  #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
  
- /**
-  * abs - return absolute value of an argument
-  * @x: the value.  If it is unsigned type, it is converted to signed type first.
-  *     char is treated as if it was signed (regardless of whether it really is)
-  *     but the macro's return type is preserved as char.
-  *
-  * Return: an absolute value of x.
-  */
- #define abs(x)	__abs_choose_expr(x, long long,				\
- 		__abs_choose_expr(x, long,				\
- 		__abs_choose_expr(x, int,				\
- 		__abs_choose_expr(x, short,				\
- 		__abs_choose_expr(x, char,				\
- 		__builtin_choose_expr(					\
- 			__builtin_types_compatible_p(typeof(x), char),	\
- 			(char)({ signed char __x = (x); __x<0?-__x:__x; }), \
- 			((void)0)))))))
- 
- #define __abs_choose_expr(x, type, other) __builtin_choose_expr(	\
- 	__builtin_types_compatible_p(typeof(x),   signed type) ||	\
- 	__builtin_types_compatible_p(typeof(x), unsigned type),		\
- 	({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
- 
- /**
-  * reciprocal_scale - "scale" a value into range [0, ep_ro)
-  * @val: value
-  * @ep_ro: right open interval endpoint
-  *
-  * Perform a "reciprocal multiplication" in order to "scale" a value into
-  * range [0, @ep_ro), where the upper interval endpoint is right-open.
-  * This is useful, e.g. for accessing a index of an array containing
-  * @ep_ro elements, for example. Think of it as sort of modulus, only that
-  * the result isn't that of modulo. ;) Note that if initial input is a
-  * small value, then result will return 0.
-  *
-  * Return: a result based on @val in interval [0, @ep_ro).
-  */
- static inline u32 reciprocal_scale(u32 val, u32 ep_ro)
- {
- 	return (u32)(((u64) val * ep_ro) >> 32);
- }
 -#ifndef CONFIG_PREEMPT_RT
 -# define cant_migrate()		cant_sleep()
 -#else
 -  /* Placeholder for now */
 -# define cant_migrate()		do { } while (0)
 -#endif
--
  #if defined(CONFIG_MMU) && \
  	(defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP))
  #define might_fault() __might_fault(__FILE__, __LINE__)

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-11-23  8:05 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-11-23  8:05 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Borislav Petkov, Dmitry Safonov, Dmitry Safonov, Jarkko Sakkinen,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Sean Christopherson, Sean Christopherson

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

Hi all,

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

  include/linux/mm.h

between commit:

  95bb7c42ac8a ("mm: Add 'mprotect' hook to struct vm_operations_struct")

from the tip tree and commit:

  6dd8e5dab7c1 ("mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio")

from the akpm-current 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 include/linux/mm.h
index e877401baae6,cd50a37aa76d..000000000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -557,15 -557,9 +557,16 @@@ enum page_entry_size 
  struct vm_operations_struct {
  	void (*open)(struct vm_area_struct * area);
  	void (*close)(struct vm_area_struct * area);
- 	int (*split)(struct vm_area_struct * area, unsigned long addr);
- 	int (*mremap)(struct vm_area_struct * area);
+ 	/* Called any time before splitting to check if it's allowed */
+ 	int (*may_split)(struct vm_area_struct *area, unsigned long addr);
+ 	int (*mremap)(struct vm_area_struct *area, unsigned long flags);
 +	/*
 +	 * Called by mprotect() to make driver-specific permission
 +	 * checks before mprotect() is finalised.   The VMA must not
 +	 * be modified.  Returns 0 if eprotect() can proceed.
 +	 */
 +	int (*mprotect)(struct vm_area_struct *vma, unsigned long start,
 +			unsigned long end, unsigned long newflags);
  	vm_fault_t (*fault)(struct vm_fault *vmf);
  	vm_fault_t (*huge_fault)(struct vm_fault *vmf,
  			enum page_entry_size pe_size);

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-11-09  6:00 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-11-09  6:00 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Mike Rapoport, Mike Rapoport

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

Hi all,

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

  arch/arc/Kconfig

between commit:

  39cac191ff37 ("arc/mm/highmem: Use generic kmap atomic implementation")

from the tip tree and commit:

  b41c56d2a9e6 ("arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM")

from the akpm-current 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/arc/Kconfig
index 1a1ee5c4c2e7,c874f8ab0341..000000000000
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@@ -505,8 -507,7 +506,8 @@@ config LINUX_RAM_BAS
  
  config HIGHMEM
  	bool "High Memory Support"
- 	select ARCH_DISCONTIGMEM_ENABLE
+ 	select HAVE_ARCH_PFN_VALID
 +	select KMAP_LOCAL
  	help
  	  With ARC 2G:2G address split, only upper 2G is directly addressable by
  	  kernel. Enable this to potentially allow access to rest of 2G and PAE

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-10-13  6:59 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-10-13  6:59 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu, Tetsuo Handa

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

Hi all,

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

  include/linux/sched.h

between commit:

  d741bf41d7c7 ("kprobes: Remove kretprobe hash")

from the tip tree and commit:

  faf4ffbfd1c5 ("fs/buffer.c: add debug print for __getblk_gfp() stall problem")

from the akpm-current 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 include/linux/sched.h
index 1695d45c2d7a,a360da173c32..000000000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1322,10 -1320,13 +1327,17 @@@ struct task_struct 
  	struct callback_head		mce_kill_me;
  #endif
  
 +#ifdef CONFIG_KRETPROBES
 +	struct llist_head               kretprobe_instances;
 +#endif
 +
+ #ifdef CONFIG_DEBUG_AID_FOR_SYZBOT
+ 	unsigned long			getblk_stamp;
+ 	unsigned int			getblk_executed;
+ 	unsigned int			getblk_bh_count;
+ 	unsigned long			getblk_bh_state;
+ #endif
+ 
  	/*
  	 * New fields for task_struct should be added above here, so that
  	 * they are included in the randomized portion of task_struct.

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-07-17 10:19 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-07-17 10:19 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Alex Belits,
	Nitesh Narayan Lal, yuqi jin, Shaokun Zhang

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

Hi all,

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

  lib/cpumask.c

between commit:

  1abdfe706a57 ("lib: Restrict cpumask_local_spread to houskeeping CPUs")

from the tip tree and commit:

  6f7ee3fd63c9 ("lib: optimize cpumask_local_spread()")

from the akpm-current 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 lib/cpumask.c
index 85da6ab4fbb5,2fecbcd8c160..000000000000
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@@ -6,7 -6,7 +6,8 @@@
  #include <linux/export.h>
  #include <linux/memblock.h>
  #include <linux/numa.h>
 +#include <linux/sched/isolation.h>
+ #include <linux/spinlock.h>
  
  /**
   * cpumask_next - get the next cpu in a cpumask
@@@ -193,40 -193,56 +194,61 @@@ void __init free_bootmem_cpumask_var(cp
  }
  #endif
  
- /**
-  * cpumask_local_spread - select the i'th cpu with local numa cpu's first
-  * @i: index number
-  * @node: local numa_node
-  *
-  * This function selects an online CPU according to a numa aware policy;
-  * local cpus are returned first, followed by non-local ones, then it
-  * wraps around.
-  *
-  * It's not very efficient, but useful for setup.
-  */
- unsigned int cpumask_local_spread(unsigned int i, int node)
+ static void calc_node_distance(int *node_dist, int node)
+ {
+ 	int i;
+ 
+ 	for (i = 0; i < nr_node_ids; i++)
+ 		node_dist[i] = node_distance(node, i);
+ }
+ 
+ static int find_nearest_node(int *node_dist, bool *used)
+ {
+ 	int i, min_dist = node_dist[0], node_id = -1;
+ 
+ 	/* Choose the first unused node to compare */
+ 	for (i = 0; i < nr_node_ids; i++) {
+ 		if (used[i] == 0) {
+ 			min_dist = node_dist[i];
+ 			node_id = i;
+ 			break;
+ 		}
+ 	}
+ 
+ 	/* Compare and return the nearest node */
+ 	for (i = 0; i < nr_node_ids; i++) {
+ 		if (node_dist[i] < min_dist && used[i] == 0) {
+ 			min_dist = node_dist[i];
+ 			node_id = i;
+ 		}
+ 	}
+ 
+ 	return node_id;
+ }
+ 
+ static unsigned int __cpumask_local_spread(unsigned int i, int node)
  {
 -	int cpu;
 +	int cpu, hk_flags;
 +	const struct cpumask *mask;
  
 +	hk_flags = HK_FLAG_DOMAIN | HK_FLAG_MANAGED_IRQ;
 +	mask = housekeeping_cpumask(hk_flags);
  	/* Wrap: we always want a cpu. */
 -	i %= num_online_cpus();
 +	i %= cpumask_weight(mask);
  
  	if (node == NUMA_NO_NODE) {
 -		for_each_cpu(cpu, cpu_online_mask)
 +		for_each_cpu(cpu, mask) {
  			if (i-- == 0)
  				return cpu;
 +		}
  	} else {
  		/* NUMA first. */
 -		for_each_cpu_and(cpu, cpumask_of_node(node), cpu_online_mask)
 +		for_each_cpu_and(cpu, cpumask_of_node(node), mask) {
  			if (i-- == 0)
  				return cpu;
 +		}
  
 -		for_each_cpu(cpu, cpu_online_mask) {
 +		for_each_cpu(cpu, mask) {
  			/* Skip NUMA nodes, done above. */
  			if (cpumask_test_cpu(cpu, cpumask_of_node(node)))
  				continue;

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2020-05-25 11:04 Stephen Rothwell
  2020-05-26  4:41 ` Singh, Balbir
@ 2020-06-03  4:43 ` Stephen Rothwell
  1 sibling, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-06-03  4:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Joerg Roedel, Balbir Singh

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

Hi all,

On Mon, 25 May 2020 21:04:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/x86/mm/tlb.c
> 
> between commit:
> 
>   83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
> 
> from the tip tree and commit:
> 
>   36c8e34d03a1 ("x86/mm: remove vmalloc faulting")
> 
> from the akpm-current tree.
> 
> diff --cc arch/x86/mm/tlb.c
> index c8524c506ab0,f3fe261e5936..000000000000
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@@ -345,48 -161,16 +345,20 @@@ void switch_mm(struct mm_struct *prev, 
>   	local_irq_restore(flags);
>   }
>   
> - static void sync_current_stack_to_mm(struct mm_struct *mm)
> - {
> - 	unsigned long sp = current_stack_pointer;
> - 	pgd_t *pgd = pgd_offset(mm, sp);
> - 
> - 	if (pgtable_l5_enabled()) {
> - 		if (unlikely(pgd_none(*pgd))) {
> - 			pgd_t *pgd_ref = pgd_offset_k(sp);
> - 
> - 			set_pgd(pgd, *pgd_ref);
> - 		}
> - 	} else {
> - 		/*
> - 		 * "pgd" is faked.  The top level entries are "p4d"s, so sync
> - 		 * the p4d.  This compiles to approximately the same code as
> - 		 * the 5-level case.
> - 		 */
> - 		p4d_t *p4d = p4d_offset(pgd, sp);
> - 
> - 		if (unlikely(p4d_none(*p4d))) {
> - 			pgd_t *pgd_ref = pgd_offset_k(sp);
> - 			p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
> - 
> - 			set_p4d(p4d, *p4d_ref);
> - 		}
> - 	}
> - }
> - 
>  -static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
>  +static inline unsigned long mm_mangle_tif_spec_bits(struct task_struct *next)
>   {
>   	unsigned long next_tif = task_thread_info(next)->flags;
>  -	unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
>  +	unsigned long spec_bits = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_SPEC_MASK;
>   
>  -	return (unsigned long)next->mm | ibpb;
>  +	BUILD_BUG_ON(TIF_SPEC_L1D_FLUSH != TIF_SPEC_IB + 1);
>  +
>  +	return (unsigned long)next->mm | spec_bits;
>   }
>   
>  -static void cond_ibpb(struct task_struct *next)
>  +static void cond_mitigation(struct task_struct *next)
>   {
>  +	unsigned long prev_mm, next_mm;
>  +
>   	if (!next || !next->mm)
>   		return;
>   
> @@@ -587,20 -343,12 +559,11 @@@ void switch_mm_irqs_off(struct mm_struc
>   		need_flush = true;
>   	} else {
>   		/*
>  -		 * Avoid user/user BTB poisoning by flushing the branch
>  -		 * predictor when switching between processes. This stops
>  -		 * one process from doing Spectre-v2 attacks on another.
>  +		 * Apply process to process speculation vulnerability
>  +		 * mitigations if applicable.
>   		 */
>  -		cond_ibpb(tsk);
>  +		cond_mitigation(tsk);
>   
> - 		if (IS_ENABLED(CONFIG_VMAP_STACK)) {
> - 			/*
> - 			 * If our current stack is in vmalloc space and isn't
> - 			 * mapped in the new pgd, we'll double-fault.  Forcibly
> - 			 * map it.
> - 			 */
> - 			sync_current_stack_to_mm(next);
> - 		}
> - 
>   		/*
>   		 * Stop remote flushes for the previous mm.
>   		 * Skip kernel threads; we never send init_mm TLB flushing IPIs,

This is now a conflict between commit

  94709049fb84 ("Merge branch 'akpm' (patches from Andrew)")

from Linus' tree and the above tip tree commit.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-29 11:05 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-29 11:05 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Arvind Sankar, Ard Biesheuvel, Mike Rapoport

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

Hi all,

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

  arch/x86/include/asm/efi.h

between commit:

  9b47c5275614 ("efi/libstub: Add definitions for console input and events")

from the tip tree and patch:

  "mm: reorder includes after introduction of linux/pgtable.h"

from the akpm-current 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/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 129e62146cbc..e7d2ccfdd507 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -3,13 +3,13 @@
 #define _ASM_X86_EFI_H
 
 #include <asm/fpu/api.h>
-#include <linux/pgtable.h>
 #include <asm/processor-flags.h>
 #include <asm/tlb.h>
 #include <asm/nospec-branch.h>
 #include <asm/mmu_context.h>
 #include <linux/build_bug.h>
 #include <linux/kernel.h>
+#include <linux/pgtable.h>
 
 extern unsigned long efi_fw_vendor, efi_config_table;
 

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

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-29 10:18 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-29 10:18 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Johannes Weiner, Rik van Riel

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

Hi all,

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

  mm/swap.c

between commit:

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

from the tip tree and commit:

  48c1ce8726a7 ("mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()")

from the akpm-current 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 mm/swap.c
index 0ac463d44cff,acd88873f076..000000000000
--- a/mm/swap.c
+++ b/mm/swap.c
@@@ -468,10 -435,17 +459,19 @@@ EXPORT_SYMBOL(mark_page_accessed)
   */
  void lru_cache_add(struct page *page)
  {
 -	struct pagevec *pvec = &get_cpu_var(lru_add_pvec);
++	struct pagevec *pvec;
+ 
  	VM_BUG_ON_PAGE(PageActive(page) && PageUnevictable(page), page);
  	VM_BUG_ON_PAGE(PageLRU(page), page);
- 	__lru_cache_add(page);
+ 
++	local_lock(&lru_pvecs.lock);
++	pvec = this_cpu_ptr(&lru_pvecs.lru_add);
+ 	get_page(page);
+ 	if (!pagevec_add(pvec, page) || PageCompound(page))
+ 		__pagevec_lru_add(pvec);
 -	put_cpu_var(lru_add_pvec);
++	local_unlock(&lru_pvecs.lock);
  }
+ EXPORT_SYMBOL(lru_cache_add);
  
  /**
   * lru_cache_add_active_or_unevictable

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-29 10:05 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-29 10:05 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Tetsuo Handa,
	Tony Luck, Borislav Petkov

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

Hi all,

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

  include/linux/sched.h

between commits:

  5567d11c21a1 ("x86/mce: Send #MC singal from task work")

from the tip tree and commit:

  e87f27165be1 ("fs/buffer.c: add debug print for __getblk_gfp() stall problem")

from the akpm-current 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 include/linux/sched.h
index 5216bd5ff4fb,98060427c53f..000000000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1303,14 -1293,13 +1307,21 @@@ struct task_struct 
  	unsigned long			prev_lowest_stack;
  #endif
  
 +#ifdef CONFIG_X86_MCE
 +	u64				mce_addr;
 +	__u64				mce_ripv : 1,
 +					mce_whole_page : 1,
 +					__mce_reserved : 62;
 +	struct callback_head		mce_kill_me;
 +#endif
 +
+ #ifdef CONFIG_DEBUG_AID_FOR_SYZBOT
+ 	unsigned long			getblk_stamp;
+ 	unsigned int			getblk_executed;
+ 	unsigned int			getblk_bh_count;
+ 	unsigned long			getblk_bh_state;
+ #endif
+ 
  	/*
  	 * New fields for task_struct should be added above here, so that
  	 * they are included in the randomized portion of task_struct.

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-29  9:58 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-29  9:58 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Julia Cartwright, Sebastian Andrzej Siewior

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

Hi all,

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

  fs/squashfs/decompressor_multi_percpu.c

between commit:

  fd56200a16c7 ("squashfs: Make use of local lock in multi_cpu decompressor")

from the tip tree and commit:

  5697b27554f3 ("squashfs-migrate-from-ll_rw_block-usage-to-bio-fix")

from the akpm-current 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 fs/squashfs/decompressor_multi_percpu.c
index e206ebfe003c,d93e12d9b712..000000000000
--- a/fs/squashfs/decompressor_multi_percpu.c
+++ b/fs/squashfs/decompressor_multi_percpu.c
@@@ -75,19 -72,18 +75,18 @@@ void squashfs_decompressor_destroy(stru
  	}
  }
  
- int squashfs_decompress(struct squashfs_sb_info *msblk, struct buffer_head **bh,
- 	int b, int offset, int length, struct squashfs_page_actor *output)
+ int squashfs_decompress(struct squashfs_sb_info *msblk, struct bio *bio,
+ 	int offset, int length, struct squashfs_page_actor *output)
  {
 -	struct squashfs_stream __percpu *percpu;
  	struct squashfs_stream *stream;
  	int res;
  
 -	percpu = (struct squashfs_stream __percpu *)msblk->stream;
 -	stream = get_cpu_ptr(percpu);
 +	local_lock(&msblk->stream->lock);
 +	stream = this_cpu_ptr(msblk->stream);
 +
- 	res = msblk->decompressor->decompress(msblk, stream->stream, bh, b,
- 			offset, length, output);
- 
+ 	res = msblk->decompressor->decompress(msblk, stream->stream, bio,
+ 					      offset, length, output);
 -	put_cpu_ptr(stream);
 +	local_unlock(&msblk->stream->lock);
  
  	if (res < 0)
  		ERROR("%s decompression failed, data probably corrupt\n",

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2020-05-25 11:04 Stephen Rothwell
@ 2020-05-26  4:41 ` Singh, Balbir
  2020-06-03  4:43 ` Stephen Rothwell
  1 sibling, 0 replies; 112+ messages in thread
From: Singh, Balbir @ 2020-05-26  4:41 UTC (permalink / raw)
  To: sfr, tglx, mingo, hpa, peterz, akpm; +Cc: jroedel, linux-kernel, linux-next

On Mon, 2020-05-25 at 21:04 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/x86/mm/tlb.c
> 
> between commit:
> 
>   83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
> 
> from the tip tree and commit:
> 
>   36c8e34d03a1 ("x86/mm: remove vmalloc faulting")
> 
> from the akpm-current 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.
> 

The changes look reasonable to me (in terms of the merge resolution).

Acked-by: Balbir Singh <bsingharora@gmail.com>


^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-25 11:04 Stephen Rothwell
  2020-05-26  4:41 ` Singh, Balbir
  2020-06-03  4:43 ` Stephen Rothwell
  0 siblings, 2 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-25 11:04 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Joerg Roedel,
	Balbir Singh

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

Hi all,

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

  arch/x86/mm/tlb.c

between commit:

  83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")

from the tip tree and commit:

  36c8e34d03a1 ("x86/mm: remove vmalloc faulting")

from the akpm-current 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/tlb.c
index c8524c506ab0,f3fe261e5936..000000000000
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@@ -345,48 -161,16 +345,20 @@@ void switch_mm(struct mm_struct *prev, 
  	local_irq_restore(flags);
  }
  
- static void sync_current_stack_to_mm(struct mm_struct *mm)
- {
- 	unsigned long sp = current_stack_pointer;
- 	pgd_t *pgd = pgd_offset(mm, sp);
- 
- 	if (pgtable_l5_enabled()) {
- 		if (unlikely(pgd_none(*pgd))) {
- 			pgd_t *pgd_ref = pgd_offset_k(sp);
- 
- 			set_pgd(pgd, *pgd_ref);
- 		}
- 	} else {
- 		/*
- 		 * "pgd" is faked.  The top level entries are "p4d"s, so sync
- 		 * the p4d.  This compiles to approximately the same code as
- 		 * the 5-level case.
- 		 */
- 		p4d_t *p4d = p4d_offset(pgd, sp);
- 
- 		if (unlikely(p4d_none(*p4d))) {
- 			pgd_t *pgd_ref = pgd_offset_k(sp);
- 			p4d_t *p4d_ref = p4d_offset(pgd_ref, sp);
- 
- 			set_p4d(p4d, *p4d_ref);
- 		}
- 	}
- }
- 
 -static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
 +static inline unsigned long mm_mangle_tif_spec_bits(struct task_struct *next)
  {
  	unsigned long next_tif = task_thread_info(next)->flags;
 -	unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
 +	unsigned long spec_bits = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_SPEC_MASK;
  
 -	return (unsigned long)next->mm | ibpb;
 +	BUILD_BUG_ON(TIF_SPEC_L1D_FLUSH != TIF_SPEC_IB + 1);
 +
 +	return (unsigned long)next->mm | spec_bits;
  }
  
 -static void cond_ibpb(struct task_struct *next)
 +static void cond_mitigation(struct task_struct *next)
  {
 +	unsigned long prev_mm, next_mm;
 +
  	if (!next || !next->mm)
  		return;
  
@@@ -587,20 -343,12 +559,11 @@@ void switch_mm_irqs_off(struct mm_struc
  		need_flush = true;
  	} else {
  		/*
 -		 * Avoid user/user BTB poisoning by flushing the branch
 -		 * predictor when switching between processes. This stops
 -		 * one process from doing Spectre-v2 attacks on another.
 +		 * Apply process to process speculation vulnerability
 +		 * mitigations if applicable.
  		 */
 -		cond_ibpb(tsk);
 +		cond_mitigation(tsk);
  
- 		if (IS_ENABLED(CONFIG_VMAP_STACK)) {
- 			/*
- 			 * If our current stack is in vmalloc space and isn't
- 			 * mapped in the new pgd, we'll double-fault.  Forcibly
- 			 * map it.
- 			 */
- 			sync_current_stack_to_mm(next);
- 		}
- 
  		/*
  		 * Stop remote flushes for the previous mm.
  		 * Skip kernel threads; we never send init_mm TLB flushing IPIs,

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-05-19 16:18 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-05-19 16:18 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kefeng Wang,
	Masami Hiramatsu

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

Hi all,

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

  kernel/kprobes.c

between commit:

  4fdd88877e52 ("kprobes: Lock kprobe_mutex while showing kprobe_blacklist")

from the tip tree and commit:

  71294f4f8167 ("kernel/kprobes.c: convert to use DEFINE_SEQ_ATTRIBUTE macro")

from the akpm-current 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/kprobes.c
index 9622ee05f5fa,9146e1a8373b..000000000000
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@@ -2506,15 -2436,10 +2496,15 @@@ static int kprobe_blacklist_seq_show(st
  	return 0;
  }
  
 +static void kprobe_blacklist_seq_stop(struct seq_file *f, void *v)
 +{
 +	mutex_unlock(&kprobe_mutex);
 +}
 +
- static const struct seq_operations kprobe_blacklist_seq_ops = {
+ static const struct seq_operations kprobe_blacklist_sops = {
  	.start = kprobe_blacklist_seq_start,
  	.next  = kprobe_blacklist_seq_next,
 -	.stop  = kprobe_seq_stop,	/* Reuse void function */
 +	.stop  = kprobe_blacklist_seq_stop,
  	.show  = kprobe_blacklist_seq_show,
  };
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-03-25  7:48 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-03-25  7:48 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Minchan Kim,
	Brian Gerst

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

Hi all,

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

  arch/x86/entry/syscalls/syscall_32.tbl
  arch/x86/entry/syscalls/syscall_64.tbl

between commits:

  cab56d3484d4 ("x86/entry: Remove ABI prefixes from functions in syscall tables")
  a845a6cf1dad ("x86/entry/32: Clean up syscall_32.tbl")

from the tip tree and commit:

  0dab66ffcdf9 ("mm/madvise: introduce process_madvise() syscall: an external memory hinting API")

from the akpm-current 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/entry/syscalls/syscall_32.tbl
index 54581ac671b4,1b2184549e27..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -11,434 -11,435 +11,435 @@@
  #
  # The abi is always "i386" for this file.
  #
 -0	i386	restart_syscall		sys_restart_syscall		__ia32_sys_restart_syscall
 -1	i386	exit			sys_exit			__ia32_sys_exit
 -2	i386	fork			sys_fork			__ia32_sys_fork
 -3	i386	read			sys_read			__ia32_sys_read
 -4	i386	write			sys_write			__ia32_sys_write
 -5	i386	open			sys_open			__ia32_compat_sys_open
 -6	i386	close			sys_close			__ia32_sys_close
 -7	i386	waitpid			sys_waitpid			__ia32_sys_waitpid
 -8	i386	creat			sys_creat			__ia32_sys_creat
 -9	i386	link			sys_link			__ia32_sys_link
 -10	i386	unlink			sys_unlink			__ia32_sys_unlink
 -11	i386	execve			sys_execve			__ia32_compat_sys_execve
 -12	i386	chdir			sys_chdir			__ia32_sys_chdir
 -13	i386	time			sys_time32			__ia32_sys_time32
 -14	i386	mknod			sys_mknod			__ia32_sys_mknod
 -15	i386	chmod			sys_chmod			__ia32_sys_chmod
 -16	i386	lchown			sys_lchown16			__ia32_sys_lchown16
 +0	i386	restart_syscall		sys_restart_syscall
 +1	i386	exit			sys_exit
 +2	i386	fork			sys_fork
 +3	i386	read			sys_read
 +4	i386	write			sys_write
 +5	i386	open			sys_open			compat_sys_open
 +6	i386	close			sys_close
 +7	i386	waitpid			sys_waitpid
 +8	i386	creat			sys_creat
 +9	i386	link			sys_link
 +10	i386	unlink			sys_unlink
 +11	i386	execve			sys_execve			compat_sys_execve
 +12	i386	chdir			sys_chdir
 +13	i386	time			sys_time32
 +14	i386	mknod			sys_mknod
 +15	i386	chmod			sys_chmod
 +16	i386	lchown			sys_lchown16
  17	i386	break
 -18	i386	oldstat			sys_stat			__ia32_sys_stat
 -19	i386	lseek			sys_lseek			__ia32_compat_sys_lseek
 -20	i386	getpid			sys_getpid			__ia32_sys_getpid
 -21	i386	mount			sys_mount			__ia32_compat_sys_mount
 -22	i386	umount			sys_oldumount			__ia32_sys_oldumount
 -23	i386	setuid			sys_setuid16			__ia32_sys_setuid16
 -24	i386	getuid			sys_getuid16			__ia32_sys_getuid16
 -25	i386	stime			sys_stime32			__ia32_sys_stime32
 -26	i386	ptrace			sys_ptrace			__ia32_compat_sys_ptrace
 -27	i386	alarm			sys_alarm			__ia32_sys_alarm
 -28	i386	oldfstat		sys_fstat			__ia32_sys_fstat
 -29	i386	pause			sys_pause			__ia32_sys_pause
 -30	i386	utime			sys_utime32			__ia32_sys_utime32
 +18	i386	oldstat			sys_stat
 +19	i386	lseek			sys_lseek			compat_sys_lseek
 +20	i386	getpid			sys_getpid
 +21	i386	mount			sys_mount			compat_sys_mount
 +22	i386	umount			sys_oldumount
 +23	i386	setuid			sys_setuid16
 +24	i386	getuid			sys_getuid16
 +25	i386	stime			sys_stime32
 +26	i386	ptrace			sys_ptrace			compat_sys_ptrace
 +27	i386	alarm			sys_alarm
 +28	i386	oldfstat		sys_fstat
 +29	i386	pause			sys_pause
 +30	i386	utime			sys_utime32
  31	i386	stty
  32	i386	gtty
 -33	i386	access			sys_access			__ia32_sys_access
 -34	i386	nice			sys_nice			__ia32_sys_nice
 +33	i386	access			sys_access
 +34	i386	nice			sys_nice
  35	i386	ftime
 -36	i386	sync			sys_sync			__ia32_sys_sync
 -37	i386	kill			sys_kill			__ia32_sys_kill
 -38	i386	rename			sys_rename			__ia32_sys_rename
 -39	i386	mkdir			sys_mkdir			__ia32_sys_mkdir
 -40	i386	rmdir			sys_rmdir			__ia32_sys_rmdir
 -41	i386	dup			sys_dup				__ia32_sys_dup
 -42	i386	pipe			sys_pipe			__ia32_sys_pipe
 -43	i386	times			sys_times			__ia32_compat_sys_times
 +36	i386	sync			sys_sync
 +37	i386	kill			sys_kill
 +38	i386	rename			sys_rename
 +39	i386	mkdir			sys_mkdir
 +40	i386	rmdir			sys_rmdir
 +41	i386	dup			sys_dup
 +42	i386	pipe			sys_pipe
 +43	i386	times			sys_times			compat_sys_times
  44	i386	prof
 -45	i386	brk			sys_brk				__ia32_sys_brk
 -46	i386	setgid			sys_setgid16			__ia32_sys_setgid16
 -47	i386	getgid			sys_getgid16			__ia32_sys_getgid16
 -48	i386	signal			sys_signal			__ia32_sys_signal
 -49	i386	geteuid			sys_geteuid16			__ia32_sys_geteuid16
 -50	i386	getegid			sys_getegid16			__ia32_sys_getegid16
 -51	i386	acct			sys_acct			__ia32_sys_acct
 -52	i386	umount2			sys_umount			__ia32_sys_umount
 +45	i386	brk			sys_brk
 +46	i386	setgid			sys_setgid16
 +47	i386	getgid			sys_getgid16
 +48	i386	signal			sys_signal
 +49	i386	geteuid			sys_geteuid16
 +50	i386	getegid			sys_getegid16
 +51	i386	acct			sys_acct
 +52	i386	umount2			sys_umount
  53	i386	lock
 -54	i386	ioctl			sys_ioctl			__ia32_compat_sys_ioctl
 -55	i386	fcntl			sys_fcntl			__ia32_compat_sys_fcntl64
 +54	i386	ioctl			sys_ioctl			compat_sys_ioctl
 +55	i386	fcntl			sys_fcntl			compat_sys_fcntl64
  56	i386	mpx
 -57	i386	setpgid			sys_setpgid			__ia32_sys_setpgid
 +57	i386	setpgid			sys_setpgid
  58	i386	ulimit
 -59	i386	oldolduname		sys_olduname			__ia32_sys_olduname
 -60	i386	umask			sys_umask			__ia32_sys_umask
 -61	i386	chroot			sys_chroot			__ia32_sys_chroot
 -62	i386	ustat			sys_ustat			__ia32_compat_sys_ustat
 -63	i386	dup2			sys_dup2			__ia32_sys_dup2
 -64	i386	getppid			sys_getppid			__ia32_sys_getppid
 -65	i386	getpgrp			sys_getpgrp			__ia32_sys_getpgrp
 -66	i386	setsid			sys_setsid			__ia32_sys_setsid
 -67	i386	sigaction		sys_sigaction			__ia32_compat_sys_sigaction
 -68	i386	sgetmask		sys_sgetmask			__ia32_sys_sgetmask
 -69	i386	ssetmask		sys_ssetmask			__ia32_sys_ssetmask
 -70	i386	setreuid		sys_setreuid16			__ia32_sys_setreuid16
 -71	i386	setregid		sys_setregid16			__ia32_sys_setregid16
 -72	i386	sigsuspend		sys_sigsuspend			__ia32_sys_sigsuspend
 -73	i386	sigpending		sys_sigpending			__ia32_compat_sys_sigpending
 -74	i386	sethostname		sys_sethostname			__ia32_sys_sethostname
 -75	i386	setrlimit		sys_setrlimit			__ia32_compat_sys_setrlimit
 -76	i386	getrlimit		sys_old_getrlimit		__ia32_compat_sys_old_getrlimit
 -77	i386	getrusage		sys_getrusage			__ia32_compat_sys_getrusage
 -78	i386	gettimeofday		sys_gettimeofday		__ia32_compat_sys_gettimeofday
 -79	i386	settimeofday		sys_settimeofday		__ia32_compat_sys_settimeofday
 -80	i386	getgroups		sys_getgroups16			__ia32_sys_getgroups16
 -81	i386	setgroups		sys_setgroups16			__ia32_sys_setgroups16
 -82	i386	select			sys_old_select			__ia32_compat_sys_old_select
 -83	i386	symlink			sys_symlink			__ia32_sys_symlink
 -84	i386	oldlstat		sys_lstat			__ia32_sys_lstat
 -85	i386	readlink		sys_readlink			__ia32_sys_readlink
 -86	i386	uselib			sys_uselib			__ia32_sys_uselib
 -87	i386	swapon			sys_swapon			__ia32_sys_swapon
 -88	i386	reboot			sys_reboot			__ia32_sys_reboot
 -89	i386	readdir			sys_old_readdir			__ia32_compat_sys_old_readdir
 -90	i386	mmap			sys_old_mmap			__ia32_compat_sys_x86_mmap
 -91	i386	munmap			sys_munmap			__ia32_sys_munmap
 -92	i386	truncate		sys_truncate			__ia32_compat_sys_truncate
 -93	i386	ftruncate		sys_ftruncate			__ia32_compat_sys_ftruncate
 -94	i386	fchmod			sys_fchmod			__ia32_sys_fchmod
 -95	i386	fchown			sys_fchown16			__ia32_sys_fchown16
 -96	i386	getpriority		sys_getpriority			__ia32_sys_getpriority
 -97	i386	setpriority		sys_setpriority			__ia32_sys_setpriority
 +59	i386	oldolduname		sys_olduname
 +60	i386	umask			sys_umask
 +61	i386	chroot			sys_chroot
 +62	i386	ustat			sys_ustat			compat_sys_ustat
 +63	i386	dup2			sys_dup2
 +64	i386	getppid			sys_getppid
 +65	i386	getpgrp			sys_getpgrp
 +66	i386	setsid			sys_setsid
 +67	i386	sigaction		sys_sigaction			compat_sys_sigaction
 +68	i386	sgetmask		sys_sgetmask
 +69	i386	ssetmask		sys_ssetmask
 +70	i386	setreuid		sys_setreuid16
 +71	i386	setregid		sys_setregid16
 +72	i386	sigsuspend		sys_sigsuspend
 +73	i386	sigpending		sys_sigpending			compat_sys_sigpending
 +74	i386	sethostname		sys_sethostname
 +75	i386	setrlimit		sys_setrlimit			compat_sys_setrlimit
 +76	i386	getrlimit		sys_old_getrlimit		compat_sys_old_getrlimit
 +77	i386	getrusage		sys_getrusage			compat_sys_getrusage
 +78	i386	gettimeofday		sys_gettimeofday		compat_sys_gettimeofday
 +79	i386	settimeofday		sys_settimeofday		compat_sys_settimeofday
 +80	i386	getgroups		sys_getgroups16
 +81	i386	setgroups		sys_setgroups16
 +82	i386	select			sys_old_select			compat_sys_old_select
 +83	i386	symlink			sys_symlink
 +84	i386	oldlstat		sys_lstat
 +85	i386	readlink		sys_readlink
 +86	i386	uselib			sys_uselib
 +87	i386	swapon			sys_swapon
 +88	i386	reboot			sys_reboot
 +89	i386	readdir			sys_old_readdir			compat_sys_old_readdir
 +90	i386	mmap			sys_old_mmap			compat_sys_ia32_mmap
 +91	i386	munmap			sys_munmap
 +92	i386	truncate		sys_truncate			compat_sys_truncate
 +93	i386	ftruncate		sys_ftruncate			compat_sys_ftruncate
 +94	i386	fchmod			sys_fchmod
 +95	i386	fchown			sys_fchown16
 +96	i386	getpriority		sys_getpriority
 +97	i386	setpriority		sys_setpriority
  98	i386	profil
 -99	i386	statfs			sys_statfs			__ia32_compat_sys_statfs
 -100	i386	fstatfs			sys_fstatfs			__ia32_compat_sys_fstatfs
 -101	i386	ioperm			sys_ioperm			__ia32_sys_ioperm
 -102	i386	socketcall		sys_socketcall			__ia32_compat_sys_socketcall
 -103	i386	syslog			sys_syslog			__ia32_sys_syslog
 -104	i386	setitimer		sys_setitimer			__ia32_compat_sys_setitimer
 -105	i386	getitimer		sys_getitimer			__ia32_compat_sys_getitimer
 -106	i386	stat			sys_newstat			__ia32_compat_sys_newstat
 -107	i386	lstat			sys_newlstat			__ia32_compat_sys_newlstat
 -108	i386	fstat			sys_newfstat			__ia32_compat_sys_newfstat
 -109	i386	olduname		sys_uname			__ia32_sys_uname
 -110	i386	iopl			sys_iopl			__ia32_sys_iopl
 -111	i386	vhangup			sys_vhangup			__ia32_sys_vhangup
 +99	i386	statfs			sys_statfs			compat_sys_statfs
 +100	i386	fstatfs			sys_fstatfs			compat_sys_fstatfs
 +101	i386	ioperm			sys_ioperm
 +102	i386	socketcall		sys_socketcall			compat_sys_socketcall
 +103	i386	syslog			sys_syslog
 +104	i386	setitimer		sys_setitimer			compat_sys_setitimer
 +105	i386	getitimer		sys_getitimer			compat_sys_getitimer
 +106	i386	stat			sys_newstat			compat_sys_newstat
 +107	i386	lstat			sys_newlstat			compat_sys_newlstat
 +108	i386	fstat			sys_newfstat			compat_sys_newfstat
 +109	i386	olduname		sys_uname
 +110	i386	iopl			sys_iopl
 +111	i386	vhangup			sys_vhangup
  112	i386	idle
 -113	i386	vm86old			sys_vm86old			__ia32_sys_ni_syscall
 -114	i386	wait4			sys_wait4			__ia32_compat_sys_wait4
 -115	i386	swapoff			sys_swapoff			__ia32_sys_swapoff
 -116	i386	sysinfo			sys_sysinfo			__ia32_compat_sys_sysinfo
 -117	i386	ipc			sys_ipc				__ia32_compat_sys_ipc
 -118	i386	fsync			sys_fsync			__ia32_sys_fsync
 -119	i386	sigreturn		sys_sigreturn			__ia32_compat_sys_sigreturn
 -120	i386	clone			sys_clone			__ia32_compat_sys_x86_clone
 -121	i386	setdomainname		sys_setdomainname		__ia32_sys_setdomainname
 -122	i386	uname			sys_newuname			__ia32_sys_newuname
 -123	i386	modify_ldt		sys_modify_ldt			__ia32_sys_modify_ldt
 -124	i386	adjtimex		sys_adjtimex_time32			__ia32_sys_adjtimex_time32
 -125	i386	mprotect		sys_mprotect			__ia32_sys_mprotect
 -126	i386	sigprocmask		sys_sigprocmask			__ia32_compat_sys_sigprocmask
 +113	i386	vm86old			sys_vm86old			sys_ni_syscall
 +114	i386	wait4			sys_wait4			compat_sys_wait4
 +115	i386	swapoff			sys_swapoff
 +116	i386	sysinfo			sys_sysinfo			compat_sys_sysinfo
 +117	i386	ipc			sys_ipc				compat_sys_ipc
 +118	i386	fsync			sys_fsync
 +119	i386	sigreturn		sys_sigreturn			compat_sys_sigreturn
 +120	i386	clone			sys_clone			compat_sys_ia32_clone
 +121	i386	setdomainname		sys_setdomainname
 +122	i386	uname			sys_newuname
 +123	i386	modify_ldt		sys_modify_ldt
 +124	i386	adjtimex		sys_adjtimex_time32
 +125	i386	mprotect		sys_mprotect
 +126	i386	sigprocmask		sys_sigprocmask			compat_sys_sigprocmask
  127	i386	create_module
 -128	i386	init_module		sys_init_module			__ia32_sys_init_module
 -129	i386	delete_module		sys_delete_module		__ia32_sys_delete_module
 +128	i386	init_module		sys_init_module
 +129	i386	delete_module		sys_delete_module
  130	i386	get_kernel_syms
 -131	i386	quotactl		sys_quotactl			__ia32_compat_sys_quotactl32
 -132	i386	getpgid			sys_getpgid			__ia32_sys_getpgid
 -133	i386	fchdir			sys_fchdir			__ia32_sys_fchdir
 -134	i386	bdflush			sys_bdflush			__ia32_sys_bdflush
 -135	i386	sysfs			sys_sysfs			__ia32_sys_sysfs
 -136	i386	personality		sys_personality			__ia32_sys_personality
 +131	i386	quotactl		sys_quotactl			compat_sys_quotactl32
 +132	i386	getpgid			sys_getpgid
 +133	i386	fchdir			sys_fchdir
 +134	i386	bdflush			sys_bdflush
 +135	i386	sysfs			sys_sysfs
 +136	i386	personality		sys_personality
  137	i386	afs_syscall
 -138	i386	setfsuid		sys_setfsuid16			__ia32_sys_setfsuid16
 -139	i386	setfsgid		sys_setfsgid16			__ia32_sys_setfsgid16
 -140	i386	_llseek			sys_llseek			__ia32_sys_llseek
 -141	i386	getdents		sys_getdents			__ia32_compat_sys_getdents
 -142	i386	_newselect		sys_select			__ia32_compat_sys_select
 -143	i386	flock			sys_flock			__ia32_sys_flock
 -144	i386	msync			sys_msync			__ia32_sys_msync
 -145	i386	readv			sys_readv			__ia32_compat_sys_readv
 -146	i386	writev			sys_writev			__ia32_compat_sys_writev
 -147	i386	getsid			sys_getsid			__ia32_sys_getsid
 -148	i386	fdatasync		sys_fdatasync			__ia32_sys_fdatasync
 -149	i386	_sysctl			sys_sysctl			__ia32_compat_sys_sysctl
 -150	i386	mlock			sys_mlock			__ia32_sys_mlock
 -151	i386	munlock			sys_munlock			__ia32_sys_munlock
 -152	i386	mlockall		sys_mlockall			__ia32_sys_mlockall
 -153	i386	munlockall		sys_munlockall			__ia32_sys_munlockall
 -154	i386	sched_setparam		sys_sched_setparam		__ia32_sys_sched_setparam
 -155	i386	sched_getparam		sys_sched_getparam		__ia32_sys_sched_getparam
 -156	i386	sched_setscheduler	sys_sched_setscheduler		__ia32_sys_sched_setscheduler
 -157	i386	sched_getscheduler	sys_sched_getscheduler		__ia32_sys_sched_getscheduler
 -158	i386	sched_yield		sys_sched_yield			__ia32_sys_sched_yield
 -159	i386	sched_get_priority_max	sys_sched_get_priority_max	__ia32_sys_sched_get_priority_max
 -160	i386	sched_get_priority_min	sys_sched_get_priority_min	__ia32_sys_sched_get_priority_min
 -161	i386	sched_rr_get_interval	sys_sched_rr_get_interval_time32	__ia32_sys_sched_rr_get_interval_time32
 -162	i386	nanosleep		sys_nanosleep_time32		__ia32_sys_nanosleep_time32
 -163	i386	mremap			sys_mremap			__ia32_sys_mremap
 -164	i386	setresuid		sys_setresuid16			__ia32_sys_setresuid16
 -165	i386	getresuid		sys_getresuid16			__ia32_sys_getresuid16
 -166	i386	vm86			sys_vm86			__ia32_sys_ni_syscall
 +138	i386	setfsuid		sys_setfsuid16
 +139	i386	setfsgid		sys_setfsgid16
 +140	i386	_llseek			sys_llseek
 +141	i386	getdents		sys_getdents			compat_sys_getdents
 +142	i386	_newselect		sys_select			compat_sys_select
 +143	i386	flock			sys_flock
 +144	i386	msync			sys_msync
 +145	i386	readv			sys_readv			compat_sys_readv
 +146	i386	writev			sys_writev			compat_sys_writev
 +147	i386	getsid			sys_getsid
 +148	i386	fdatasync		sys_fdatasync
 +149	i386	_sysctl			sys_sysctl			compat_sys_sysctl
 +150	i386	mlock			sys_mlock
 +151	i386	munlock			sys_munlock
 +152	i386	mlockall		sys_mlockall
 +153	i386	munlockall		sys_munlockall
 +154	i386	sched_setparam		sys_sched_setparam
 +155	i386	sched_getparam		sys_sched_getparam
 +156	i386	sched_setscheduler	sys_sched_setscheduler
 +157	i386	sched_getscheduler	sys_sched_getscheduler
 +158	i386	sched_yield		sys_sched_yield
 +159	i386	sched_get_priority_max	sys_sched_get_priority_max
 +160	i386	sched_get_priority_min	sys_sched_get_priority_min
 +161	i386	sched_rr_get_interval	sys_sched_rr_get_interval_time32
 +162	i386	nanosleep		sys_nanosleep_time32
 +163	i386	mremap			sys_mremap
 +164	i386	setresuid		sys_setresuid16
 +165	i386	getresuid		sys_getresuid16
 +166	i386	vm86			sys_vm86			sys_ni_syscall
  167	i386	query_module
 -168	i386	poll			sys_poll			__ia32_sys_poll
 +168	i386	poll			sys_poll
  169	i386	nfsservctl
 -170	i386	setresgid		sys_setresgid16			__ia32_sys_setresgid16
 -171	i386	getresgid		sys_getresgid16			__ia32_sys_getresgid16
 -172	i386	prctl			sys_prctl			__ia32_sys_prctl
 -173	i386	rt_sigreturn		sys_rt_sigreturn		__ia32_compat_sys_rt_sigreturn
 -174	i386	rt_sigaction		sys_rt_sigaction		__ia32_compat_sys_rt_sigaction
 -175	i386	rt_sigprocmask		sys_rt_sigprocmask		__ia32_compat_sys_rt_sigprocmask
 -176	i386	rt_sigpending		sys_rt_sigpending		__ia32_compat_sys_rt_sigpending
 -177	i386	rt_sigtimedwait		sys_rt_sigtimedwait_time32	__ia32_compat_sys_rt_sigtimedwait_time32
 -178	i386	rt_sigqueueinfo		sys_rt_sigqueueinfo		__ia32_compat_sys_rt_sigqueueinfo
 -179	i386	rt_sigsuspend		sys_rt_sigsuspend		__ia32_compat_sys_rt_sigsuspend
 -180	i386	pread64			sys_pread64			__ia32_compat_sys_x86_pread
 -181	i386	pwrite64		sys_pwrite64			__ia32_compat_sys_x86_pwrite
 -182	i386	chown			sys_chown16			__ia32_sys_chown16
 -183	i386	getcwd			sys_getcwd			__ia32_sys_getcwd
 -184	i386	capget			sys_capget			__ia32_sys_capget
 -185	i386	capset			sys_capset			__ia32_sys_capset
 -186	i386	sigaltstack		sys_sigaltstack			__ia32_compat_sys_sigaltstack
 -187	i386	sendfile		sys_sendfile			__ia32_compat_sys_sendfile
 +170	i386	setresgid		sys_setresgid16
 +171	i386	getresgid		sys_getresgid16
 +172	i386	prctl			sys_prctl
 +173	i386	rt_sigreturn		sys_rt_sigreturn		compat_sys_rt_sigreturn
 +174	i386	rt_sigaction		sys_rt_sigaction		compat_sys_rt_sigaction
 +175	i386	rt_sigprocmask		sys_rt_sigprocmask		compat_sys_rt_sigprocmask
 +176	i386	rt_sigpending		sys_rt_sigpending		compat_sys_rt_sigpending
 +177	i386	rt_sigtimedwait		sys_rt_sigtimedwait_time32	compat_sys_rt_sigtimedwait_time32
 +178	i386	rt_sigqueueinfo		sys_rt_sigqueueinfo		compat_sys_rt_sigqueueinfo
 +179	i386	rt_sigsuspend		sys_rt_sigsuspend		compat_sys_rt_sigsuspend
 +180	i386	pread64			sys_ia32_pread64
 +181	i386	pwrite64		sys_ia32_pwrite64
 +182	i386	chown			sys_chown16
 +183	i386	getcwd			sys_getcwd
 +184	i386	capget			sys_capget
 +185	i386	capset			sys_capset
 +186	i386	sigaltstack		sys_sigaltstack			compat_sys_sigaltstack
 +187	i386	sendfile		sys_sendfile			compat_sys_sendfile
  188	i386	getpmsg
  189	i386	putpmsg
 -190	i386	vfork			sys_vfork			__ia32_sys_vfork
 -191	i386	ugetrlimit		sys_getrlimit			__ia32_compat_sys_getrlimit
 -192	i386	mmap2			sys_mmap_pgoff			__ia32_sys_mmap_pgoff
 -193	i386	truncate64		sys_truncate64			__ia32_compat_sys_x86_truncate64
 -194	i386	ftruncate64		sys_ftruncate64			__ia32_compat_sys_x86_ftruncate64
 -195	i386	stat64			sys_stat64			__ia32_compat_sys_x86_stat64
 -196	i386	lstat64			sys_lstat64			__ia32_compat_sys_x86_lstat64
 -197	i386	fstat64			sys_fstat64			__ia32_compat_sys_x86_fstat64
 -198	i386	lchown32		sys_lchown			__ia32_sys_lchown
 -199	i386	getuid32		sys_getuid			__ia32_sys_getuid
 -200	i386	getgid32		sys_getgid			__ia32_sys_getgid
 -201	i386	geteuid32		sys_geteuid			__ia32_sys_geteuid
 -202	i386	getegid32		sys_getegid			__ia32_sys_getegid
 -203	i386	setreuid32		sys_setreuid			__ia32_sys_setreuid
 -204	i386	setregid32		sys_setregid			__ia32_sys_setregid
 -205	i386	getgroups32		sys_getgroups			__ia32_sys_getgroups
 -206	i386	setgroups32		sys_setgroups			__ia32_sys_setgroups
 -207	i386	fchown32		sys_fchown			__ia32_sys_fchown
 -208	i386	setresuid32		sys_setresuid			__ia32_sys_setresuid
 -209	i386	getresuid32		sys_getresuid			__ia32_sys_getresuid
 -210	i386	setresgid32		sys_setresgid			__ia32_sys_setresgid
 -211	i386	getresgid32		sys_getresgid			__ia32_sys_getresgid
 -212	i386	chown32			sys_chown			__ia32_sys_chown
 -213	i386	setuid32		sys_setuid			__ia32_sys_setuid
 -214	i386	setgid32		sys_setgid			__ia32_sys_setgid
 -215	i386	setfsuid32		sys_setfsuid			__ia32_sys_setfsuid
 -216	i386	setfsgid32		sys_setfsgid			__ia32_sys_setfsgid
 -217	i386	pivot_root		sys_pivot_root			__ia32_sys_pivot_root
 -218	i386	mincore			sys_mincore			__ia32_sys_mincore
 -219	i386	madvise			sys_madvise			__ia32_sys_madvise
 -220	i386	getdents64		sys_getdents64			__ia32_sys_getdents64
 -221	i386	fcntl64			sys_fcntl64			__ia32_compat_sys_fcntl64
 +190	i386	vfork			sys_vfork
 +191	i386	ugetrlimit		sys_getrlimit			compat_sys_getrlimit
 +192	i386	mmap2			sys_mmap_pgoff
 +193	i386	truncate64		sys_ia32_truncate64
 +194	i386	ftruncate64		sys_ia32_ftruncate64
 +195	i386	stat64			sys_stat64			compat_sys_ia32_stat64
 +196	i386	lstat64			sys_lstat64			compat_sys_ia32_lstat64
 +197	i386	fstat64			sys_fstat64			compat_sys_ia32_fstat64
 +198	i386	lchown32		sys_lchown
 +199	i386	getuid32		sys_getuid
 +200	i386	getgid32		sys_getgid
 +201	i386	geteuid32		sys_geteuid
 +202	i386	getegid32		sys_getegid
 +203	i386	setreuid32		sys_setreuid
 +204	i386	setregid32		sys_setregid
 +205	i386	getgroups32		sys_getgroups
 +206	i386	setgroups32		sys_setgroups
 +207	i386	fchown32		sys_fchown
 +208	i386	setresuid32		sys_setresuid
 +209	i386	getresuid32		sys_getresuid
 +210	i386	setresgid32		sys_setresgid
 +211	i386	getresgid32		sys_getresgid
 +212	i386	chown32			sys_chown
 +213	i386	setuid32		sys_setuid
 +214	i386	setgid32		sys_setgid
 +215	i386	setfsuid32		sys_setfsuid
 +216	i386	setfsgid32		sys_setfsgid
 +217	i386	pivot_root		sys_pivot_root
 +218	i386	mincore			sys_mincore
 +219	i386	madvise			sys_madvise
 +220	i386	getdents64		sys_getdents64
 +221	i386	fcntl64			sys_fcntl64			compat_sys_fcntl64
  # 222 is unused
  # 223 is unused
 -224	i386	gettid			sys_gettid			__ia32_sys_gettid
 -225	i386	readahead		sys_readahead			__ia32_compat_sys_x86_readahead
 -226	i386	setxattr		sys_setxattr			__ia32_sys_setxattr
 -227	i386	lsetxattr		sys_lsetxattr			__ia32_sys_lsetxattr
 -228	i386	fsetxattr		sys_fsetxattr			__ia32_sys_fsetxattr
 -229	i386	getxattr		sys_getxattr			__ia32_sys_getxattr
 -230	i386	lgetxattr		sys_lgetxattr			__ia32_sys_lgetxattr
 -231	i386	fgetxattr		sys_fgetxattr			__ia32_sys_fgetxattr
 -232	i386	listxattr		sys_listxattr			__ia32_sys_listxattr
 -233	i386	llistxattr		sys_llistxattr			__ia32_sys_llistxattr
 -234	i386	flistxattr		sys_flistxattr			__ia32_sys_flistxattr
 -235	i386	removexattr		sys_removexattr			__ia32_sys_removexattr
 -236	i386	lremovexattr		sys_lremovexattr		__ia32_sys_lremovexattr
 -237	i386	fremovexattr		sys_fremovexattr		__ia32_sys_fremovexattr
 -238	i386	tkill			sys_tkill			__ia32_sys_tkill
 -239	i386	sendfile64		sys_sendfile64			__ia32_sys_sendfile64
 -240	i386	futex			sys_futex_time32		__ia32_sys_futex_time32
 -241	i386	sched_setaffinity	sys_sched_setaffinity		__ia32_compat_sys_sched_setaffinity
 -242	i386	sched_getaffinity	sys_sched_getaffinity		__ia32_compat_sys_sched_getaffinity
 -243	i386	set_thread_area		sys_set_thread_area		__ia32_sys_set_thread_area
 -244	i386	get_thread_area		sys_get_thread_area		__ia32_sys_get_thread_area
 -245	i386	io_setup		sys_io_setup			__ia32_compat_sys_io_setup
 -246	i386	io_destroy		sys_io_destroy			__ia32_sys_io_destroy
 -247	i386	io_getevents		sys_io_getevents_time32		__ia32_sys_io_getevents_time32
 -248	i386	io_submit		sys_io_submit			__ia32_compat_sys_io_submit
 -249	i386	io_cancel		sys_io_cancel			__ia32_sys_io_cancel
 -250	i386	fadvise64		sys_fadvise64			__ia32_compat_sys_x86_fadvise64
 +224	i386	gettid			sys_gettid
 +225	i386	readahead		sys_ia32_readahead
 +226	i386	setxattr		sys_setxattr
 +227	i386	lsetxattr		sys_lsetxattr
 +228	i386	fsetxattr		sys_fsetxattr
 +229	i386	getxattr		sys_getxattr
 +230	i386	lgetxattr		sys_lgetxattr
 +231	i386	fgetxattr		sys_fgetxattr
 +232	i386	listxattr		sys_listxattr
 +233	i386	llistxattr		sys_llistxattr
 +234	i386	flistxattr		sys_flistxattr
 +235	i386	removexattr		sys_removexattr
 +236	i386	lremovexattr		sys_lremovexattr
 +237	i386	fremovexattr		sys_fremovexattr
 +238	i386	tkill			sys_tkill
 +239	i386	sendfile64		sys_sendfile64
 +240	i386	futex			sys_futex_time32
 +241	i386	sched_setaffinity	sys_sched_setaffinity		compat_sys_sched_setaffinity
 +242	i386	sched_getaffinity	sys_sched_getaffinity		compat_sys_sched_getaffinity
 +243	i386	set_thread_area		sys_set_thread_area
 +244	i386	get_thread_area		sys_get_thread_area
 +245	i386	io_setup		sys_io_setup			compat_sys_io_setup
 +246	i386	io_destroy		sys_io_destroy
 +247	i386	io_getevents		sys_io_getevents_time32
 +248	i386	io_submit		sys_io_submit			compat_sys_io_submit
 +249	i386	io_cancel		sys_io_cancel
 +250	i386	fadvise64		sys_ia32_fadvise64
  # 251 is available for reuse (was briefly sys_set_zone_reclaim)
 -252	i386	exit_group		sys_exit_group			__ia32_sys_exit_group
 -253	i386	lookup_dcookie		sys_lookup_dcookie		__ia32_compat_sys_lookup_dcookie
 -254	i386	epoll_create		sys_epoll_create		__ia32_sys_epoll_create
 -255	i386	epoll_ctl		sys_epoll_ctl			__ia32_sys_epoll_ctl
 -256	i386	epoll_wait		sys_epoll_wait			__ia32_sys_epoll_wait
 -257	i386	remap_file_pages	sys_remap_file_pages		__ia32_sys_remap_file_pages
 -258	i386	set_tid_address		sys_set_tid_address		__ia32_sys_set_tid_address
 -259	i386	timer_create		sys_timer_create		__ia32_compat_sys_timer_create
 -260	i386	timer_settime		sys_timer_settime32		__ia32_sys_timer_settime32
 -261	i386	timer_gettime		sys_timer_gettime32		__ia32_sys_timer_gettime32
 -262	i386	timer_getoverrun	sys_timer_getoverrun		__ia32_sys_timer_getoverrun
 -263	i386	timer_delete		sys_timer_delete		__ia32_sys_timer_delete
 -264	i386	clock_settime		sys_clock_settime32		__ia32_sys_clock_settime32
 -265	i386	clock_gettime		sys_clock_gettime32		__ia32_sys_clock_gettime32
 -266	i386	clock_getres		sys_clock_getres_time32		__ia32_sys_clock_getres_time32
 -267	i386	clock_nanosleep		sys_clock_nanosleep_time32	__ia32_sys_clock_nanosleep_time32
 -268	i386	statfs64		sys_statfs64			__ia32_compat_sys_statfs64
 -269	i386	fstatfs64		sys_fstatfs64			__ia32_compat_sys_fstatfs64
 -270	i386	tgkill			sys_tgkill			__ia32_sys_tgkill
 -271	i386	utimes			sys_utimes_time32		__ia32_sys_utimes_time32
 -272	i386	fadvise64_64		sys_fadvise64_64		__ia32_compat_sys_x86_fadvise64_64
 +252	i386	exit_group		sys_exit_group
 +253	i386	lookup_dcookie		sys_lookup_dcookie		compat_sys_lookup_dcookie
 +254	i386	epoll_create		sys_epoll_create
 +255	i386	epoll_ctl		sys_epoll_ctl
 +256	i386	epoll_wait		sys_epoll_wait
 +257	i386	remap_file_pages	sys_remap_file_pages
 +258	i386	set_tid_address		sys_set_tid_address
 +259	i386	timer_create		sys_timer_create		compat_sys_timer_create
 +260	i386	timer_settime		sys_timer_settime32
 +261	i386	timer_gettime		sys_timer_gettime32
 +262	i386	timer_getoverrun	sys_timer_getoverrun
 +263	i386	timer_delete		sys_timer_delete
 +264	i386	clock_settime		sys_clock_settime32
 +265	i386	clock_gettime		sys_clock_gettime32
 +266	i386	clock_getres		sys_clock_getres_time32
 +267	i386	clock_nanosleep		sys_clock_nanosleep_time32
 +268	i386	statfs64		sys_statfs64			compat_sys_statfs64
 +269	i386	fstatfs64		sys_fstatfs64			compat_sys_fstatfs64
 +270	i386	tgkill			sys_tgkill
 +271	i386	utimes			sys_utimes_time32
 +272	i386	fadvise64_64		sys_ia32_fadvise64_64
  273	i386	vserver
 -274	i386	mbind			sys_mbind			__ia32_sys_mbind
 -275	i386	get_mempolicy		sys_get_mempolicy		__ia32_compat_sys_get_mempolicy
 -276	i386	set_mempolicy		sys_set_mempolicy		__ia32_sys_set_mempolicy
 -277	i386	mq_open			sys_mq_open			__ia32_compat_sys_mq_open
 -278	i386	mq_unlink		sys_mq_unlink			__ia32_sys_mq_unlink
 -279	i386	mq_timedsend		sys_mq_timedsend_time32		__ia32_sys_mq_timedsend_time32
 -280	i386	mq_timedreceive		sys_mq_timedreceive_time32	__ia32_sys_mq_timedreceive_time32
 -281	i386	mq_notify		sys_mq_notify			__ia32_compat_sys_mq_notify
 -282	i386	mq_getsetattr		sys_mq_getsetattr		__ia32_compat_sys_mq_getsetattr
 -283	i386	kexec_load		sys_kexec_load			__ia32_compat_sys_kexec_load
 -284	i386	waitid			sys_waitid			__ia32_compat_sys_waitid
 +274	i386	mbind			sys_mbind
 +275	i386	get_mempolicy		sys_get_mempolicy		compat_sys_get_mempolicy
 +276	i386	set_mempolicy		sys_set_mempolicy
 +277	i386	mq_open			sys_mq_open			compat_sys_mq_open
 +278	i386	mq_unlink		sys_mq_unlink
 +279	i386	mq_timedsend		sys_mq_timedsend_time32
 +280	i386	mq_timedreceive		sys_mq_timedreceive_time32
 +281	i386	mq_notify		sys_mq_notify			compat_sys_mq_notify
 +282	i386	mq_getsetattr		sys_mq_getsetattr		compat_sys_mq_getsetattr
 +283	i386	kexec_load		sys_kexec_load			compat_sys_kexec_load
 +284	i386	waitid			sys_waitid			compat_sys_waitid
  # 285 sys_setaltroot
 -286	i386	add_key			sys_add_key			__ia32_sys_add_key
 -287	i386	request_key		sys_request_key			__ia32_sys_request_key
 -288	i386	keyctl			sys_keyctl			__ia32_compat_sys_keyctl
 -289	i386	ioprio_set		sys_ioprio_set			__ia32_sys_ioprio_set
 -290	i386	ioprio_get		sys_ioprio_get			__ia32_sys_ioprio_get
 -291	i386	inotify_init		sys_inotify_init		__ia32_sys_inotify_init
 -292	i386	inotify_add_watch	sys_inotify_add_watch		__ia32_sys_inotify_add_watch
 -293	i386	inotify_rm_watch	sys_inotify_rm_watch		__ia32_sys_inotify_rm_watch
 -294	i386	migrate_pages		sys_migrate_pages		__ia32_sys_migrate_pages
 -295	i386	openat			sys_openat			__ia32_compat_sys_openat
 -296	i386	mkdirat			sys_mkdirat			__ia32_sys_mkdirat
 -297	i386	mknodat			sys_mknodat			__ia32_sys_mknodat
 -298	i386	fchownat		sys_fchownat			__ia32_sys_fchownat
 -299	i386	futimesat		sys_futimesat_time32		__ia32_sys_futimesat_time32
 -300	i386	fstatat64		sys_fstatat64			__ia32_compat_sys_x86_fstatat
 -301	i386	unlinkat		sys_unlinkat			__ia32_sys_unlinkat
 -302	i386	renameat		sys_renameat			__ia32_sys_renameat
 -303	i386	linkat			sys_linkat			__ia32_sys_linkat
 -304	i386	symlinkat		sys_symlinkat			__ia32_sys_symlinkat
 -305	i386	readlinkat		sys_readlinkat			__ia32_sys_readlinkat
 -306	i386	fchmodat		sys_fchmodat			__ia32_sys_fchmodat
 -307	i386	faccessat		sys_faccessat			__ia32_sys_faccessat
 -308	i386	pselect6		sys_pselect6_time32		__ia32_compat_sys_pselect6_time32
 -309	i386	ppoll			sys_ppoll_time32		__ia32_compat_sys_ppoll_time32
 -310	i386	unshare			sys_unshare			__ia32_sys_unshare
 -311	i386	set_robust_list		sys_set_robust_list		__ia32_compat_sys_set_robust_list
 -312	i386	get_robust_list		sys_get_robust_list		__ia32_compat_sys_get_robust_list
 -313	i386	splice			sys_splice			__ia32_sys_splice
 -314	i386	sync_file_range		sys_sync_file_range		__ia32_compat_sys_x86_sync_file_range
 -315	i386	tee			sys_tee				__ia32_sys_tee
 -316	i386	vmsplice		sys_vmsplice			__ia32_compat_sys_vmsplice
 -317	i386	move_pages		sys_move_pages			__ia32_compat_sys_move_pages
 -318	i386	getcpu			sys_getcpu			__ia32_sys_getcpu
 -319	i386	epoll_pwait		sys_epoll_pwait			__ia32_sys_epoll_pwait
 -320	i386	utimensat		sys_utimensat_time32		__ia32_sys_utimensat_time32
 -321	i386	signalfd		sys_signalfd			__ia32_compat_sys_signalfd
 -322	i386	timerfd_create		sys_timerfd_create		__ia32_sys_timerfd_create
 -323	i386	eventfd			sys_eventfd			__ia32_sys_eventfd
 -324	i386	fallocate		sys_fallocate			__ia32_compat_sys_x86_fallocate
 -325	i386	timerfd_settime		sys_timerfd_settime32		__ia32_sys_timerfd_settime32
 -326	i386	timerfd_gettime		sys_timerfd_gettime32		__ia32_sys_timerfd_gettime32
 -327	i386	signalfd4		sys_signalfd4			__ia32_compat_sys_signalfd4
 -328	i386	eventfd2		sys_eventfd2			__ia32_sys_eventfd2
 -329	i386	epoll_create1		sys_epoll_create1		__ia32_sys_epoll_create1
 -330	i386	dup3			sys_dup3			__ia32_sys_dup3
 -331	i386	pipe2			sys_pipe2			__ia32_sys_pipe2
 -332	i386	inotify_init1		sys_inotify_init1		__ia32_sys_inotify_init1
 -333	i386	preadv			sys_preadv			__ia32_compat_sys_preadv
 -334	i386	pwritev			sys_pwritev			__ia32_compat_sys_pwritev
 -335	i386	rt_tgsigqueueinfo	sys_rt_tgsigqueueinfo		__ia32_compat_sys_rt_tgsigqueueinfo
 -336	i386	perf_event_open		sys_perf_event_open		__ia32_sys_perf_event_open
 -337	i386	recvmmsg		sys_recvmmsg_time32		__ia32_compat_sys_recvmmsg_time32
 -338	i386	fanotify_init		sys_fanotify_init		__ia32_sys_fanotify_init
 -339	i386	fanotify_mark		sys_fanotify_mark		__ia32_compat_sys_fanotify_mark
 -340	i386	prlimit64		sys_prlimit64			__ia32_sys_prlimit64
 -341	i386	name_to_handle_at	sys_name_to_handle_at		__ia32_sys_name_to_handle_at
 -342	i386	open_by_handle_at	sys_open_by_handle_at		__ia32_compat_sys_open_by_handle_at
 -343	i386	clock_adjtime		sys_clock_adjtime32		__ia32_sys_clock_adjtime32
 -344	i386	syncfs			sys_syncfs			__ia32_sys_syncfs
 -345	i386	sendmmsg		sys_sendmmsg			__ia32_compat_sys_sendmmsg
 -346	i386	setns			sys_setns			__ia32_sys_setns
 -347	i386	process_vm_readv	sys_process_vm_readv		__ia32_compat_sys_process_vm_readv
 -348	i386	process_vm_writev	sys_process_vm_writev		__ia32_compat_sys_process_vm_writev
 -349	i386	kcmp			sys_kcmp			__ia32_sys_kcmp
 -350	i386	finit_module		sys_finit_module		__ia32_sys_finit_module
 -351	i386	sched_setattr		sys_sched_setattr		__ia32_sys_sched_setattr
 -352	i386	sched_getattr		sys_sched_getattr		__ia32_sys_sched_getattr
 -353	i386	renameat2		sys_renameat2			__ia32_sys_renameat2
 -354	i386	seccomp			sys_seccomp			__ia32_sys_seccomp
 -355	i386	getrandom		sys_getrandom			__ia32_sys_getrandom
 -356	i386	memfd_create		sys_memfd_create		__ia32_sys_memfd_create
 -357	i386	bpf			sys_bpf				__ia32_sys_bpf
 -358	i386	execveat		sys_execveat			__ia32_compat_sys_execveat
 -359	i386	socket			sys_socket			__ia32_sys_socket
 -360	i386	socketpair		sys_socketpair			__ia32_sys_socketpair
 -361	i386	bind			sys_bind			__ia32_sys_bind
 -362	i386	connect			sys_connect			__ia32_sys_connect
 -363	i386	listen			sys_listen			__ia32_sys_listen
 -364	i386	accept4			sys_accept4			__ia32_sys_accept4
 -365	i386	getsockopt		sys_getsockopt			__ia32_compat_sys_getsockopt
 -366	i386	setsockopt		sys_setsockopt			__ia32_compat_sys_setsockopt
 -367	i386	getsockname		sys_getsockname			__ia32_sys_getsockname
 -368	i386	getpeername		sys_getpeername			__ia32_sys_getpeername
 -369	i386	sendto			sys_sendto			__ia32_sys_sendto
 -370	i386	sendmsg			sys_sendmsg			__ia32_compat_sys_sendmsg
 -371	i386	recvfrom		sys_recvfrom			__ia32_compat_sys_recvfrom
 -372	i386	recvmsg			sys_recvmsg			__ia32_compat_sys_recvmsg
 -373	i386	shutdown		sys_shutdown			__ia32_sys_shutdown
 -374	i386	userfaultfd		sys_userfaultfd			__ia32_sys_userfaultfd
 -375	i386	membarrier		sys_membarrier			__ia32_sys_membarrier
 -376	i386	mlock2			sys_mlock2			__ia32_sys_mlock2
 -377	i386	copy_file_range		sys_copy_file_range		__ia32_sys_copy_file_range
 -378	i386	preadv2			sys_preadv2			__ia32_compat_sys_preadv2
 -379	i386	pwritev2		sys_pwritev2			__ia32_compat_sys_pwritev2
 -380	i386	pkey_mprotect		sys_pkey_mprotect		__ia32_sys_pkey_mprotect
 -381	i386	pkey_alloc		sys_pkey_alloc			__ia32_sys_pkey_alloc
 -382	i386	pkey_free		sys_pkey_free			__ia32_sys_pkey_free
 -383	i386	statx			sys_statx			__ia32_sys_statx
 -384	i386	arch_prctl		sys_arch_prctl			__ia32_compat_sys_arch_prctl
 -385	i386	io_pgetevents		sys_io_pgetevents_time32	__ia32_compat_sys_io_pgetevents
 -386	i386	rseq			sys_rseq			__ia32_sys_rseq
 -393	i386	semget			sys_semget    			__ia32_sys_semget
 -394	i386	semctl			sys_semctl    			__ia32_compat_sys_semctl
 -395	i386	shmget			sys_shmget    			__ia32_sys_shmget
 -396	i386	shmctl			sys_shmctl    			__ia32_compat_sys_shmctl
 -397	i386	shmat			sys_shmat     			__ia32_compat_sys_shmat
 -398	i386	shmdt			sys_shmdt     			__ia32_sys_shmdt
 -399	i386	msgget			sys_msgget    			__ia32_sys_msgget
 -400	i386	msgsnd			sys_msgsnd    			__ia32_compat_sys_msgsnd
 -401	i386	msgrcv			sys_msgrcv    			__ia32_compat_sys_msgrcv
 -402	i386	msgctl			sys_msgctl    			__ia32_compat_sys_msgctl
 -403	i386	clock_gettime64		sys_clock_gettime		__ia32_sys_clock_gettime
 -404	i386	clock_settime64		sys_clock_settime		__ia32_sys_clock_settime
 -405	i386	clock_adjtime64		sys_clock_adjtime		__ia32_sys_clock_adjtime
 -406	i386	clock_getres_time64	sys_clock_getres		__ia32_sys_clock_getres
 -407	i386	clock_nanosleep_time64	sys_clock_nanosleep		__ia32_sys_clock_nanosleep
 -408	i386	timer_gettime64		sys_timer_gettime		__ia32_sys_timer_gettime
 -409	i386	timer_settime64		sys_timer_settime		__ia32_sys_timer_settime
 -410	i386	timerfd_gettime64	sys_timerfd_gettime		__ia32_sys_timerfd_gettime
 -411	i386	timerfd_settime64	sys_timerfd_settime		__ia32_sys_timerfd_settime
 -412	i386	utimensat_time64	sys_utimensat			__ia32_sys_utimensat
 -413	i386	pselect6_time64		sys_pselect6			__ia32_compat_sys_pselect6_time64
 -414	i386	ppoll_time64		sys_ppoll			__ia32_compat_sys_ppoll_time64
 -416	i386	io_pgetevents_time64	sys_io_pgetevents		__ia32_sys_io_pgetevents
 -417	i386	recvmmsg_time64		sys_recvmmsg			__ia32_compat_sys_recvmmsg_time64
 -418	i386	mq_timedsend_time64	sys_mq_timedsend		__ia32_sys_mq_timedsend
 -419	i386	mq_timedreceive_time64	sys_mq_timedreceive		__ia32_sys_mq_timedreceive
 -420	i386	semtimedop_time64	sys_semtimedop			__ia32_sys_semtimedop
 -421	i386	rt_sigtimedwait_time64	sys_rt_sigtimedwait		__ia32_compat_sys_rt_sigtimedwait_time64
 -422	i386	futex_time64		sys_futex			__ia32_sys_futex
 -423	i386	sched_rr_get_interval_time64	sys_sched_rr_get_interval	__ia32_sys_sched_rr_get_interval
 -424	i386	pidfd_send_signal	sys_pidfd_send_signal		__ia32_sys_pidfd_send_signal
 -425	i386	io_uring_setup		sys_io_uring_setup		__ia32_sys_io_uring_setup
 -426	i386	io_uring_enter		sys_io_uring_enter		__ia32_sys_io_uring_enter
 -427	i386	io_uring_register	sys_io_uring_register		__ia32_sys_io_uring_register
 -428	i386	open_tree		sys_open_tree			__ia32_sys_open_tree
 -429	i386	move_mount		sys_move_mount			__ia32_sys_move_mount
 -430	i386	fsopen			sys_fsopen			__ia32_sys_fsopen
 -431	i386	fsconfig		sys_fsconfig			__ia32_sys_fsconfig
 -432	i386	fsmount			sys_fsmount			__ia32_sys_fsmount
 -433	i386	fspick			sys_fspick			__ia32_sys_fspick
 -434	i386	pidfd_open		sys_pidfd_open			__ia32_sys_pidfd_open
 -435	i386	clone3			sys_clone3			__ia32_sys_clone3
 -437	i386	openat2			sys_openat2			__ia32_sys_openat2
 -438	i386	pidfd_getfd		sys_pidfd_getfd			__ia32_sys_pidfd_getfd
 -439	i386	process_madvise		sys_process_madvise		__ia32_sys_process_madvise
 +286	i386	add_key			sys_add_key
 +287	i386	request_key		sys_request_key
 +288	i386	keyctl			sys_keyctl			compat_sys_keyctl
 +289	i386	ioprio_set		sys_ioprio_set
 +290	i386	ioprio_get		sys_ioprio_get
 +291	i386	inotify_init		sys_inotify_init
 +292	i386	inotify_add_watch	sys_inotify_add_watch
 +293	i386	inotify_rm_watch	sys_inotify_rm_watch
 +294	i386	migrate_pages		sys_migrate_pages
 +295	i386	openat			sys_openat			compat_sys_openat
 +296	i386	mkdirat			sys_mkdirat
 +297	i386	mknodat			sys_mknodat
 +298	i386	fchownat		sys_fchownat
 +299	i386	futimesat		sys_futimesat_time32
 +300	i386	fstatat64		sys_fstatat64			compat_sys_ia32_fstatat64
 +301	i386	unlinkat		sys_unlinkat
 +302	i386	renameat		sys_renameat
 +303	i386	linkat			sys_linkat
 +304	i386	symlinkat		sys_symlinkat
 +305	i386	readlinkat		sys_readlinkat
 +306	i386	fchmodat		sys_fchmodat
 +307	i386	faccessat		sys_faccessat
 +308	i386	pselect6		sys_pselect6_time32		compat_sys_pselect6_time32
 +309	i386	ppoll			sys_ppoll_time32		compat_sys_ppoll_time32
 +310	i386	unshare			sys_unshare
 +311	i386	set_robust_list		sys_set_robust_list		compat_sys_set_robust_list
 +312	i386	get_robust_list		sys_get_robust_list		compat_sys_get_robust_list
 +313	i386	splice			sys_splice
 +314	i386	sync_file_range		sys_ia32_sync_file_range
 +315	i386	tee			sys_tee
 +316	i386	vmsplice		sys_vmsplice			compat_sys_vmsplice
 +317	i386	move_pages		sys_move_pages			compat_sys_move_pages
 +318	i386	getcpu			sys_getcpu
 +319	i386	epoll_pwait		sys_epoll_pwait
 +320	i386	utimensat		sys_utimensat_time32
 +321	i386	signalfd		sys_signalfd			compat_sys_signalfd
 +322	i386	timerfd_create		sys_timerfd_create
 +323	i386	eventfd			sys_eventfd
 +324	i386	fallocate		sys_ia32_fallocate
 +325	i386	timerfd_settime		sys_timerfd_settime32
 +326	i386	timerfd_gettime		sys_timerfd_gettime32
 +327	i386	signalfd4		sys_signalfd4			compat_sys_signalfd4
 +328	i386	eventfd2		sys_eventfd2
 +329	i386	epoll_create1		sys_epoll_create1
 +330	i386	dup3			sys_dup3
 +331	i386	pipe2			sys_pipe2
 +332	i386	inotify_init1		sys_inotify_init1
 +333	i386	preadv			sys_preadv			compat_sys_preadv
 +334	i386	pwritev			sys_pwritev			compat_sys_pwritev
 +335	i386	rt_tgsigqueueinfo	sys_rt_tgsigqueueinfo		compat_sys_rt_tgsigqueueinfo
 +336	i386	perf_event_open		sys_perf_event_open
 +337	i386	recvmmsg		sys_recvmmsg_time32		compat_sys_recvmmsg_time32
 +338	i386	fanotify_init		sys_fanotify_init
 +339	i386	fanotify_mark		sys_fanotify_mark		compat_sys_fanotify_mark
 +340	i386	prlimit64		sys_prlimit64
 +341	i386	name_to_handle_at	sys_name_to_handle_at
 +342	i386	open_by_handle_at	sys_open_by_handle_at		compat_sys_open_by_handle_at
 +343	i386	clock_adjtime		sys_clock_adjtime32
 +344	i386	syncfs			sys_syncfs
 +345	i386	sendmmsg		sys_sendmmsg			compat_sys_sendmmsg
 +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
 +350	i386	finit_module		sys_finit_module
 +351	i386	sched_setattr		sys_sched_setattr
 +352	i386	sched_getattr		sys_sched_getattr
 +353	i386	renameat2		sys_renameat2
 +354	i386	seccomp			sys_seccomp
 +355	i386	getrandom		sys_getrandom
 +356	i386	memfd_create		sys_memfd_create
 +357	i386	bpf			sys_bpf
 +358	i386	execveat		sys_execveat			compat_sys_execveat
 +359	i386	socket			sys_socket
 +360	i386	socketpair		sys_socketpair
 +361	i386	bind			sys_bind
 +362	i386	connect			sys_connect
 +363	i386	listen			sys_listen
 +364	i386	accept4			sys_accept4
 +365	i386	getsockopt		sys_getsockopt			compat_sys_getsockopt
 +366	i386	setsockopt		sys_setsockopt			compat_sys_setsockopt
 +367	i386	getsockname		sys_getsockname
 +368	i386	getpeername		sys_getpeername
 +369	i386	sendto			sys_sendto
 +370	i386	sendmsg			sys_sendmsg			compat_sys_sendmsg
 +371	i386	recvfrom		sys_recvfrom			compat_sys_recvfrom
 +372	i386	recvmsg			sys_recvmsg			compat_sys_recvmsg
 +373	i386	shutdown		sys_shutdown
 +374	i386	userfaultfd		sys_userfaultfd
 +375	i386	membarrier		sys_membarrier
 +376	i386	mlock2			sys_mlock2
 +377	i386	copy_file_range		sys_copy_file_range
 +378	i386	preadv2			sys_preadv2			compat_sys_preadv2
 +379	i386	pwritev2		sys_pwritev2			compat_sys_pwritev2
 +380	i386	pkey_mprotect		sys_pkey_mprotect
 +381	i386	pkey_alloc		sys_pkey_alloc
 +382	i386	pkey_free		sys_pkey_free
 +383	i386	statx			sys_statx
 +384	i386	arch_prctl		sys_arch_prctl			compat_sys_arch_prctl
 +385	i386	io_pgetevents		sys_io_pgetevents_time32	compat_sys_io_pgetevents
 +386	i386	rseq			sys_rseq
 +393	i386	semget			sys_semget
 +394	i386	semctl			sys_semctl    			compat_sys_semctl
 +395	i386	shmget			sys_shmget
 +396	i386	shmctl			sys_shmctl    			compat_sys_shmctl
 +397	i386	shmat			sys_shmat     			compat_sys_shmat
 +398	i386	shmdt			sys_shmdt
 +399	i386	msgget			sys_msgget
 +400	i386	msgsnd			sys_msgsnd    			compat_sys_msgsnd
 +401	i386	msgrcv			sys_msgrcv    			compat_sys_msgrcv
 +402	i386	msgctl			sys_msgctl    			compat_sys_msgctl
 +403	i386	clock_gettime64		sys_clock_gettime
 +404	i386	clock_settime64		sys_clock_settime
 +405	i386	clock_adjtime64		sys_clock_adjtime
 +406	i386	clock_getres_time64	sys_clock_getres
 +407	i386	clock_nanosleep_time64	sys_clock_nanosleep
 +408	i386	timer_gettime64		sys_timer_gettime
 +409	i386	timer_settime64		sys_timer_settime
 +410	i386	timerfd_gettime64	sys_timerfd_gettime
 +411	i386	timerfd_settime64	sys_timerfd_settime
 +412	i386	utimensat_time64	sys_utimensat
 +413	i386	pselect6_time64		sys_pselect6			compat_sys_pselect6_time64
 +414	i386	ppoll_time64		sys_ppoll			compat_sys_ppoll_time64
 +416	i386	io_pgetevents_time64	sys_io_pgetevents
 +417	i386	recvmmsg_time64		sys_recvmmsg			compat_sys_recvmmsg_time64
 +418	i386	mq_timedsend_time64	sys_mq_timedsend
 +419	i386	mq_timedreceive_time64	sys_mq_timedreceive
 +420	i386	semtimedop_time64	sys_semtimedop
 +421	i386	rt_sigtimedwait_time64	sys_rt_sigtimedwait		compat_sys_rt_sigtimedwait_time64
 +422	i386	futex_time64		sys_futex
 +423	i386	sched_rr_get_interval_time64	sys_sched_rr_get_interval
 +424	i386	pidfd_send_signal	sys_pidfd_send_signal
 +425	i386	io_uring_setup		sys_io_uring_setup
 +426	i386	io_uring_enter		sys_io_uring_enter
 +427	i386	io_uring_register	sys_io_uring_register
 +428	i386	open_tree		sys_open_tree
 +429	i386	move_mount		sys_move_mount
 +430	i386	fsopen			sys_fsopen
 +431	i386	fsconfig		sys_fsconfig
 +432	i386	fsmount			sys_fsmount
 +433	i386	fspick			sys_fspick
 +434	i386	pidfd_open		sys_pidfd_open
 +435	i386	clone3			sys_clone3
 +437	i386	openat2			sys_openat2
 +438	i386	pidfd_getfd		sys_pidfd_getfd
++439	i386	process_madvise		sys_process_madvise
diff --cc arch/x86/entry/syscalls/syscall_64.tbl
index 37b844f839bc,82d60eb1e00d..000000000000
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@@ -194,171 -194,172 +194,172 @@@
  183	common	afs_syscall
  184	common	tuxcall
  185	common	security
 -186	common	gettid			__x64_sys_gettid
 -187	common	readahead		__x64_sys_readahead
 -188	common	setxattr		__x64_sys_setxattr
 -189	common	lsetxattr		__x64_sys_lsetxattr
 -190	common	fsetxattr		__x64_sys_fsetxattr
 -191	common	getxattr		__x64_sys_getxattr
 -192	common	lgetxattr		__x64_sys_lgetxattr
 -193	common	fgetxattr		__x64_sys_fgetxattr
 -194	common	listxattr		__x64_sys_listxattr
 -195	common	llistxattr		__x64_sys_llistxattr
 -196	common	flistxattr		__x64_sys_flistxattr
 -197	common	removexattr		__x64_sys_removexattr
 -198	common	lremovexattr		__x64_sys_lremovexattr
 -199	common	fremovexattr		__x64_sys_fremovexattr
 -200	common	tkill			__x64_sys_tkill
 -201	common	time			__x64_sys_time
 -202	common	futex			__x64_sys_futex
 -203	common	sched_setaffinity	__x64_sys_sched_setaffinity
 -204	common	sched_getaffinity	__x64_sys_sched_getaffinity
 +186	common	gettid			sys_gettid
 +187	common	readahead		sys_readahead
 +188	common	setxattr		sys_setxattr
 +189	common	lsetxattr		sys_lsetxattr
 +190	common	fsetxattr		sys_fsetxattr
 +191	common	getxattr		sys_getxattr
 +192	common	lgetxattr		sys_lgetxattr
 +193	common	fgetxattr		sys_fgetxattr
 +194	common	listxattr		sys_listxattr
 +195	common	llistxattr		sys_llistxattr
 +196	common	flistxattr		sys_flistxattr
 +197	common	removexattr		sys_removexattr
 +198	common	lremovexattr		sys_lremovexattr
 +199	common	fremovexattr		sys_fremovexattr
 +200	common	tkill			sys_tkill
 +201	common	time			sys_time
 +202	common	futex			sys_futex
 +203	common	sched_setaffinity	sys_sched_setaffinity
 +204	common	sched_getaffinity	sys_sched_getaffinity
  205	64	set_thread_area
 -206	64	io_setup		__x64_sys_io_setup
 -207	common	io_destroy		__x64_sys_io_destroy
 -208	common	io_getevents		__x64_sys_io_getevents
 -209	64	io_submit		__x64_sys_io_submit
 -210	common	io_cancel		__x64_sys_io_cancel
 +206	64	io_setup		sys_io_setup
 +207	common	io_destroy		sys_io_destroy
 +208	common	io_getevents		sys_io_getevents
 +209	64	io_submit		sys_io_submit
 +210	common	io_cancel		sys_io_cancel
  211	64	get_thread_area
 -212	common	lookup_dcookie		__x64_sys_lookup_dcookie
 -213	common	epoll_create		__x64_sys_epoll_create
 +212	common	lookup_dcookie		sys_lookup_dcookie
 +213	common	epoll_create		sys_epoll_create
  214	64	epoll_ctl_old
  215	64	epoll_wait_old
 -216	common	remap_file_pages	__x64_sys_remap_file_pages
 -217	common	getdents64		__x64_sys_getdents64
 -218	common	set_tid_address		__x64_sys_set_tid_address
 -219	common	restart_syscall		__x64_sys_restart_syscall
 -220	common	semtimedop		__x64_sys_semtimedop
 -221	common	fadvise64		__x64_sys_fadvise64
 -222	64	timer_create		__x64_sys_timer_create
 -223	common	timer_settime		__x64_sys_timer_settime
 -224	common	timer_gettime		__x64_sys_timer_gettime
 -225	common	timer_getoverrun	__x64_sys_timer_getoverrun
 -226	common	timer_delete		__x64_sys_timer_delete
 -227	common	clock_settime		__x64_sys_clock_settime
 -228	common	clock_gettime		__x64_sys_clock_gettime
 -229	common	clock_getres		__x64_sys_clock_getres
 -230	common	clock_nanosleep		__x64_sys_clock_nanosleep
 -231	common	exit_group		__x64_sys_exit_group
 -232	common	epoll_wait		__x64_sys_epoll_wait
 -233	common	epoll_ctl		__x64_sys_epoll_ctl
 -234	common	tgkill			__x64_sys_tgkill
 -235	common	utimes			__x64_sys_utimes
 +216	common	remap_file_pages	sys_remap_file_pages
 +217	common	getdents64		sys_getdents64
 +218	common	set_tid_address		sys_set_tid_address
 +219	common	restart_syscall		sys_restart_syscall
 +220	common	semtimedop		sys_semtimedop
 +221	common	fadvise64		sys_fadvise64
 +222	64	timer_create		sys_timer_create
 +223	common	timer_settime		sys_timer_settime
 +224	common	timer_gettime		sys_timer_gettime
 +225	common	timer_getoverrun	sys_timer_getoverrun
 +226	common	timer_delete		sys_timer_delete
 +227	common	clock_settime		sys_clock_settime
 +228	common	clock_gettime		sys_clock_gettime
 +229	common	clock_getres		sys_clock_getres
 +230	common	clock_nanosleep		sys_clock_nanosleep
 +231	common	exit_group		sys_exit_group
 +232	common	epoll_wait		sys_epoll_wait
 +233	common	epoll_ctl		sys_epoll_ctl
 +234	common	tgkill			sys_tgkill
 +235	common	utimes			sys_utimes
  236	64	vserver
 -237	common	mbind			__x64_sys_mbind
 -238	common	set_mempolicy		__x64_sys_set_mempolicy
 -239	common	get_mempolicy		__x64_sys_get_mempolicy
 -240	common	mq_open			__x64_sys_mq_open
 -241	common	mq_unlink		__x64_sys_mq_unlink
 -242	common	mq_timedsend		__x64_sys_mq_timedsend
 -243	common	mq_timedreceive		__x64_sys_mq_timedreceive
 -244	64	mq_notify		__x64_sys_mq_notify
 -245	common	mq_getsetattr		__x64_sys_mq_getsetattr
 -246	64	kexec_load		__x64_sys_kexec_load
 -247	64	waitid			__x64_sys_waitid
 -248	common	add_key			__x64_sys_add_key
 -249	common	request_key		__x64_sys_request_key
 -250	common	keyctl			__x64_sys_keyctl
 -251	common	ioprio_set		__x64_sys_ioprio_set
 -252	common	ioprio_get		__x64_sys_ioprio_get
 -253	common	inotify_init		__x64_sys_inotify_init
 -254	common	inotify_add_watch	__x64_sys_inotify_add_watch
 -255	common	inotify_rm_watch	__x64_sys_inotify_rm_watch
 -256	common	migrate_pages		__x64_sys_migrate_pages
 -257	common	openat			__x64_sys_openat
 -258	common	mkdirat			__x64_sys_mkdirat
 -259	common	mknodat			__x64_sys_mknodat
 -260	common	fchownat		__x64_sys_fchownat
 -261	common	futimesat		__x64_sys_futimesat
 -262	common	newfstatat		__x64_sys_newfstatat
 -263	common	unlinkat		__x64_sys_unlinkat
 -264	common	renameat		__x64_sys_renameat
 -265	common	linkat			__x64_sys_linkat
 -266	common	symlinkat		__x64_sys_symlinkat
 -267	common	readlinkat		__x64_sys_readlinkat
 -268	common	fchmodat		__x64_sys_fchmodat
 -269	common	faccessat		__x64_sys_faccessat
 -270	common	pselect6		__x64_sys_pselect6
 -271	common	ppoll			__x64_sys_ppoll
 -272	common	unshare			__x64_sys_unshare
 -273	64	set_robust_list		__x64_sys_set_robust_list
 -274	64	get_robust_list		__x64_sys_get_robust_list
 -275	common	splice			__x64_sys_splice
 -276	common	tee			__x64_sys_tee
 -277	common	sync_file_range		__x64_sys_sync_file_range
 -278	64	vmsplice		__x64_sys_vmsplice
 -279	64	move_pages		__x64_sys_move_pages
 -280	common	utimensat		__x64_sys_utimensat
 -281	common	epoll_pwait		__x64_sys_epoll_pwait
 -282	common	signalfd		__x64_sys_signalfd
 -283	common	timerfd_create		__x64_sys_timerfd_create
 -284	common	eventfd			__x64_sys_eventfd
 -285	common	fallocate		__x64_sys_fallocate
 -286	common	timerfd_settime		__x64_sys_timerfd_settime
 -287	common	timerfd_gettime		__x64_sys_timerfd_gettime
 -288	common	accept4			__x64_sys_accept4
 -289	common	signalfd4		__x64_sys_signalfd4
 -290	common	eventfd2		__x64_sys_eventfd2
 -291	common	epoll_create1		__x64_sys_epoll_create1
 -292	common	dup3			__x64_sys_dup3
 -293	common	pipe2			__x64_sys_pipe2
 -294	common	inotify_init1		__x64_sys_inotify_init1
 -295	64	preadv			__x64_sys_preadv
 -296	64	pwritev			__x64_sys_pwritev
 -297	64	rt_tgsigqueueinfo	__x64_sys_rt_tgsigqueueinfo
 -298	common	perf_event_open		__x64_sys_perf_event_open
 -299	64	recvmmsg		__x64_sys_recvmmsg
 -300	common	fanotify_init		__x64_sys_fanotify_init
 -301	common	fanotify_mark		__x64_sys_fanotify_mark
 -302	common	prlimit64		__x64_sys_prlimit64
 -303	common	name_to_handle_at	__x64_sys_name_to_handle_at
 -304	common	open_by_handle_at	__x64_sys_open_by_handle_at
 -305	common	clock_adjtime		__x64_sys_clock_adjtime
 -306	common	syncfs			__x64_sys_syncfs
 -307	64	sendmmsg		__x64_sys_sendmmsg
 -308	common	setns			__x64_sys_setns
 -309	common	getcpu			__x64_sys_getcpu
 -310	64	process_vm_readv	__x64_sys_process_vm_readv
 -311	64	process_vm_writev	__x64_sys_process_vm_writev
 -312	common	kcmp			__x64_sys_kcmp
 -313	common	finit_module		__x64_sys_finit_module
 -314	common	sched_setattr		__x64_sys_sched_setattr
 -315	common	sched_getattr		__x64_sys_sched_getattr
 -316	common	renameat2		__x64_sys_renameat2
 -317	common	seccomp			__x64_sys_seccomp
 -318	common	getrandom		__x64_sys_getrandom
 -319	common	memfd_create		__x64_sys_memfd_create
 -320	common	kexec_file_load		__x64_sys_kexec_file_load
 -321	common	bpf			__x64_sys_bpf
 -322	64	execveat		__x64_sys_execveat/ptregs
 -323	common	userfaultfd		__x64_sys_userfaultfd
 -324	common	membarrier		__x64_sys_membarrier
 -325	common	mlock2			__x64_sys_mlock2
 -326	common	copy_file_range		__x64_sys_copy_file_range
 -327	64	preadv2			__x64_sys_preadv2
 -328	64	pwritev2		__x64_sys_pwritev2
 -329	common	pkey_mprotect		__x64_sys_pkey_mprotect
 -330	common	pkey_alloc		__x64_sys_pkey_alloc
 -331	common	pkey_free		__x64_sys_pkey_free
 -332	common	statx			__x64_sys_statx
 -333	common	io_pgetevents		__x64_sys_io_pgetevents
 -334	common	rseq			__x64_sys_rseq
 +237	common	mbind			sys_mbind
 +238	common	set_mempolicy		sys_set_mempolicy
 +239	common	get_mempolicy		sys_get_mempolicy
 +240	common	mq_open			sys_mq_open
 +241	common	mq_unlink		sys_mq_unlink
 +242	common	mq_timedsend		sys_mq_timedsend
 +243	common	mq_timedreceive		sys_mq_timedreceive
 +244	64	mq_notify		sys_mq_notify
 +245	common	mq_getsetattr		sys_mq_getsetattr
 +246	64	kexec_load		sys_kexec_load
 +247	64	waitid			sys_waitid
 +248	common	add_key			sys_add_key
 +249	common	request_key		sys_request_key
 +250	common	keyctl			sys_keyctl
 +251	common	ioprio_set		sys_ioprio_set
 +252	common	ioprio_get		sys_ioprio_get
 +253	common	inotify_init		sys_inotify_init
 +254	common	inotify_add_watch	sys_inotify_add_watch
 +255	common	inotify_rm_watch	sys_inotify_rm_watch
 +256	common	migrate_pages		sys_migrate_pages
 +257	common	openat			sys_openat
 +258	common	mkdirat			sys_mkdirat
 +259	common	mknodat			sys_mknodat
 +260	common	fchownat		sys_fchownat
 +261	common	futimesat		sys_futimesat
 +262	common	newfstatat		sys_newfstatat
 +263	common	unlinkat		sys_unlinkat
 +264	common	renameat		sys_renameat
 +265	common	linkat			sys_linkat
 +266	common	symlinkat		sys_symlinkat
 +267	common	readlinkat		sys_readlinkat
 +268	common	fchmodat		sys_fchmodat
 +269	common	faccessat		sys_faccessat
 +270	common	pselect6		sys_pselect6
 +271	common	ppoll			sys_ppoll
 +272	common	unshare			sys_unshare
 +273	64	set_robust_list		sys_set_robust_list
 +274	64	get_robust_list		sys_get_robust_list
 +275	common	splice			sys_splice
 +276	common	tee			sys_tee
 +277	common	sync_file_range		sys_sync_file_range
 +278	64	vmsplice		sys_vmsplice
 +279	64	move_pages		sys_move_pages
 +280	common	utimensat		sys_utimensat
 +281	common	epoll_pwait		sys_epoll_pwait
 +282	common	signalfd		sys_signalfd
 +283	common	timerfd_create		sys_timerfd_create
 +284	common	eventfd			sys_eventfd
 +285	common	fallocate		sys_fallocate
 +286	common	timerfd_settime		sys_timerfd_settime
 +287	common	timerfd_gettime		sys_timerfd_gettime
 +288	common	accept4			sys_accept4
 +289	common	signalfd4		sys_signalfd4
 +290	common	eventfd2		sys_eventfd2
 +291	common	epoll_create1		sys_epoll_create1
 +292	common	dup3			sys_dup3
 +293	common	pipe2			sys_pipe2
 +294	common	inotify_init1		sys_inotify_init1
 +295	64	preadv			sys_preadv
 +296	64	pwritev			sys_pwritev
 +297	64	rt_tgsigqueueinfo	sys_rt_tgsigqueueinfo
 +298	common	perf_event_open		sys_perf_event_open
 +299	64	recvmmsg		sys_recvmmsg
 +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	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	common	kcmp			sys_kcmp
 +313	common	finit_module		sys_finit_module
 +314	common	sched_setattr		sys_sched_setattr
 +315	common	sched_getattr		sys_sched_getattr
 +316	common	renameat2		sys_renameat2
 +317	common	seccomp			sys_seccomp
 +318	common	getrandom		sys_getrandom
 +319	common	memfd_create		sys_memfd_create
 +320	common	kexec_file_load		sys_kexec_file_load
 +321	common	bpf			sys_bpf
 +322	64	execveat		sys_execveat
 +323	common	userfaultfd		sys_userfaultfd
 +324	common	membarrier		sys_membarrier
 +325	common	mlock2			sys_mlock2
 +326	common	copy_file_range		sys_copy_file_range
 +327	64	preadv2			sys_preadv2
 +328	64	pwritev2		sys_pwritev2
 +329	common	pkey_mprotect		sys_pkey_mprotect
 +330	common	pkey_alloc		sys_pkey_alloc
 +331	common	pkey_free		sys_pkey_free
 +332	common	statx			sys_statx
 +333	common	io_pgetevents		sys_io_pgetevents
 +334	common	rseq			sys_rseq
  # don't use numbers 387 through 423, add new calls after the last
  # 'common' entry
 -424	common	pidfd_send_signal	__x64_sys_pidfd_send_signal
 -425	common	io_uring_setup		__x64_sys_io_uring_setup
 -426	common	io_uring_enter		__x64_sys_io_uring_enter
 -427	common	io_uring_register	__x64_sys_io_uring_register
 -428	common	open_tree		__x64_sys_open_tree
 -429	common	move_mount		__x64_sys_move_mount
 -430	common	fsopen			__x64_sys_fsopen
 -431	common	fsconfig		__x64_sys_fsconfig
 -432	common	fsmount			__x64_sys_fsmount
 -433	common	fspick			__x64_sys_fspick
 -434	common	pidfd_open		__x64_sys_pidfd_open
 -435	common	clone3			__x64_sys_clone3/ptregs
 -437	common	openat2			__x64_sys_openat2
 -438	common	pidfd_getfd		__x64_sys_pidfd_getfd
 -439	common	process_madvise		__x64_sys_process_madvise
 +424	common	pidfd_send_signal	sys_pidfd_send_signal
 +425	common	io_uring_setup		sys_io_uring_setup
 +426	common	io_uring_enter		sys_io_uring_enter
 +427	common	io_uring_register	sys_io_uring_register
 +428	common	open_tree		sys_open_tree
 +429	common	move_mount		sys_move_mount
 +430	common	fsopen			sys_fsopen
 +431	common	fsconfig		sys_fsconfig
 +432	common	fsmount			sys_fsmount
 +433	common	fspick			sys_fspick
 +434	common	pidfd_open		sys_pidfd_open
 +435	common	clone3			sys_clone3
 +437	common	openat2			sys_openat2
 +438	common	pidfd_getfd		sys_pidfd_getfd
++439	common	process_madvise		sys_process_madvise
  
  #
  # x32-specific system call numbers start at 512 to avoid cache impact

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-03-19  6:42 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-03-19  6:42 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Thomas Hellstrom, Borislav Petkov, Andrea Arcangeli, Peter Xu

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

Hi all,

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

  arch/x86/include/asm/pgtable_types.h

between commit:

  6db73f17c5f1 ("x86: Don't let pgprot_modify() change the page encryption bit")

from the tip tree and commit:

  faaa52178603 ("userfaultfd: wp: add WP pagetable tracking to x86")

from the akpm-current 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/include/asm/pgtable_types.h
index 65c2ecd730c5,e24a2ecf9475..000000000000
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@@ -118,7 -127,7 +127,8 @@@
   */
  #define _PAGE_CHG_MASK	(PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT |		\
  			 _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY |	\
- 			 _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC)
 -			 _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_UFFD_WP)
++			 _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC |	\
++			 _PAGE_UFFD_WP)
  #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
  
  /*

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-01-20  6:37 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-01-20  6:37 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Wang Long,
	Alexey Dobriyan

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

Hi all,

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

  kernel/sched/psi.c

between commit:

  3d817689a62c ("sched/psi: create /proc/pressure and /proc/pressure/{io|memory|cpu} only when psi enabled")

from the tip tree and patch:

  "proc: convert everything to "struct proc_ops""

from the akpm-current 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/psi.c
index db7b50bba3f1,faad3d11b9db..000000000000
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@@ -1280,12 -1280,10 +1280,12 @@@ static const struct proc_ops psi_cpu_pr
  
  static int __init psi_proc_init(void)
  {
 -	proc_mkdir("pressure", NULL);
 -	proc_create("pressure/io", 0, NULL, &psi_io_proc_ops);
 -	proc_create("pressure/memory", 0, NULL, &psi_memory_proc_ops);
 -	proc_create("pressure/cpu", 0, NULL, &psi_cpu_proc_ops);
 +	if (psi_enable) {
 +		proc_mkdir("pressure", NULL);
- 		proc_create("pressure/io", 0, NULL, &psi_io_fops);
- 		proc_create("pressure/memory", 0, NULL, &psi_memory_fops);
- 		proc_create("pressure/cpu", 0, NULL, &psi_cpu_fops);
++		proc_create("pressure/io", 0, NULL, &psi_io_proc_ops);
++		proc_create("pressure/memory", 0, NULL, &psi_memory_proc_ops);
++		proc_create("pressure/cpu", 0, NULL, &psi_cpu_proc_ops);
 +	}
  	return 0;
  }
  module_init(psi_proc_init);

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2020-01-20  6:30 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2020-01-20  6:30 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Arnd Bergmann, Alexey Dobriyan

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

Hi all,

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

  arch/x86/kernel/apic/x2apic_uv_x.c

between commit:

  d0b778880448 ("x86/apic/uv: Avoid unused variable warning")

from the tip tree and patch:

  "proc: convert everything to "struct proc_ops""

from the akpm-current tree.

I fixed it up (I just used the tip tree version) 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 --]

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2019-10-31  5:43 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2019-10-31  5:43 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Julien Grall

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

Hi all,

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

  lib/ubsan.c

between commit:

  9a50dcaf0416 ("ubsan, x86: Annotate and allow __ubsan_handle_shift_out_of_bounds() in uaccess regions")

from the tip tree and commit:

  edbefc568464 ("lib/ubsan: don't serialize UBSAN report")

from the akpm-current 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 lib/ubsan.c
index 0c4681118fcd,39d5952c4273..000000000000
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@@ -374,12 -359,11 +359,12 @@@ void __ubsan_handle_shift_out_of_bounds
  	struct type_descriptor *lhs_type = data->lhs_type;
  	char rhs_str[VALUE_LENGTH];
  	char lhs_str[VALUE_LENGTH];
 +	unsigned long ua_flags = user_access_save();
  
  	if (suppress_report(&data->location))
 -		return;
 +		goto out;
  
- 	ubsan_prologue(&data->location, &flags);
+ 	ubsan_prologue(&data->location);
  
  	val_to_string(rhs_str, sizeof(rhs_str), rhs_type, rhs);
  	val_to_string(lhs_str, sizeof(lhs_str), lhs_type, lhs);
@@@ -402,9 -386,7 +387,9 @@@
  			lhs_str, rhs_str,
  			lhs_type->type_name);
  
- 	ubsan_epilogue(&flags);
+ 	ubsan_epilogue();
 +out:
 +	user_access_restore(ua_flags);
  }
  EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2019-06-24 10:24 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2019-06-24 10:24 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Waiman Long

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

Hi all,

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

  lib/debugobjects.c

between commit:

  d5f34153e526 ("debugobjects: Move printk out of db->lock critical sections")

from the tip tree and commit:

  8b6b497dfb11 ("lib/debugobjects.c: move printk out of db lock critical sections")

from the akpm-current tree.

I fixed it up (I reverted the akpm-current tree version) 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 --]

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2019-05-01 11:10 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2019-05-01 11:10 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Rick Edgecombe, Roman Gushchin

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

Hi all,

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

  mm/vmalloc.c

between commit:

  bade3b4bdcdb ("mm/vmalloc.c: refactor __vunmap() to avoid duplicated call to find_vm_area()")

from the tip tree and commit:

  868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions")

from the akpm-current tree.

I fixed it up (I made an attempt ta a fix 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 mm/vmalloc.c
index e5e9e1fcac01,4a91acce4b5f..000000000000
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@@ -1490,94 -2103,16 +2110,83 @@@ static struct vm_struct *__remove_vm_ar
   */
  struct vm_struct *remove_vm_area(const void *addr)
  {
+ 	struct vm_struct *vm = NULL;
  	struct vmap_area *va;
  
- 	might_sleep();
- 
  	va = find_vmap_area((unsigned long)addr);
- 	if (va && va->flags & VM_VM_AREA) {
- 		struct vm_struct *vm = va->vm;
- 
- 		spin_lock(&vmap_area_lock);
- 		va->vm = NULL;
- 		va->flags &= ~VM_VM_AREA;
- 		va->flags |= VM_LAZY_FREE;
- 		spin_unlock(&vmap_area_lock);
- 
- 		kasan_free_shadow(vm);
- 		free_unmap_vmap_area(va);
+ 	if (va && va->flags & VM_VM_AREA)
+ 		vm = __remove_vm_area(va);
  
- 		return vm;
- 	}
- 	return NULL;
+ 	return vm;
  }
  
 +static inline void set_area_direct_map(const struct vm_struct *area,
 +				       int (*set_direct_map)(struct page *page))
 +{
 +	int i;
 +
 +	for (i = 0; i < area->nr_pages; i++)
 +		if (page_address(area->pages[i]))
 +			set_direct_map(area->pages[i]);
 +}
 +
 +/* Handle removing and resetting vm mappings related to the vm_struct. */
- static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages)
++static void vm_remove_mappings(struct vmap_area *va, int deallocate_pages)
 +{
++	struct vm_struct *area = va->vm;
 +	unsigned long addr = (unsigned long)area->addr;
 +	unsigned long start = ULONG_MAX, end = 0;
 +	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
 +	int i;
 +
 +	/*
 +	 * The below block can be removed when all architectures that have
 +	 * direct map permissions also have set_direct_map_() implementations.
 +	 * This is concerned with resetting the direct map any an vm alias with
 +	 * execute permissions, without leaving a RW+X window.
 +	 */
 +	if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
 +		set_memory_nx(addr, area->nr_pages);
 +		set_memory_rw(addr, area->nr_pages);
 +	}
 +
- 	remove_vm_area(area->addr);
++	__remove_vm_area(va);
 +
 +	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */
 +	if (!flush_reset)
 +		return;
 +
 +	/*
 +	 * If not deallocating pages, just do the flush of the VM area and
 +	 * return.
 +	 */
 +	if (!deallocate_pages) {
 +		vm_unmap_aliases();
 +		return;
 +	}
 +
 +	/*
 +	 * If execution gets here, flush the vm mapping and reset the direct
 +	 * map. Find the start and end range of the direct mappings to make sure
 +	 * the vm_unmap_aliases() flush includes the direct map.
 +	 */
 +	for (i = 0; i < area->nr_pages; i++) {
 +		if (page_address(area->pages[i])) {
 +			start = min(addr, start);
 +			end = max(addr, end);
 +		}
 +	}
 +
 +	/*
 +	 * Set direct map to something invalid so that it won't be cached if
 +	 * there are any accesses after the TLB flush, then flush the TLB and
 +	 * reset the direct map permissions to the default.
 +	 */
 +	set_area_direct_map(area, set_direct_map_invalid_noflush);
 +	_vm_unmap_aliases(start, end, 1);
 +	set_area_direct_map(area, set_direct_map_default_noflush);
 +}
 +
  static void __vunmap(const void *addr, int deallocate_pages)
  {
  	struct vm_struct *area;
@@@ -1599,8 -2136,7 +2210,8 @@@
  	debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
  	debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
  
- 	vm_remove_mappings(area, deallocate_pages);
 -	__remove_vm_area(va);
++	vm_remove_mappings(va, deallocate_pages);
 +
  	if (deallocate_pages) {
  		int i;
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2019-01-31  4:31 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2019-01-31  4:31 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Aneesh Kumar K.V

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

Hi all,

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

  include/linux/sched.h

between commit:

  15917dc02841 ("sched: Remove stale PF_MUTEX_TESTER bit")

from the tip tree and commit:

  ca299cb98649 ("mm/cma: add PF flag to force non cma alloc")

from the akpm-current 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 include/linux/sched.h
index bb68abafac29,1ef3995b7564..000000000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1409,6 -1423,8 +1423,7 @@@ extern struct pid *cad_pid
  #define PF_UMH			0x02000000	/* I'm an Usermodehelper process */
  #define PF_NO_SETAFFINITY	0x04000000	/* Userland is not allowed to meddle with cpus_allowed */
  #define PF_MCE_EARLY		0x08000000      /* Early kill for mce process policy */
+ #define PF_MEMALLOC_NOCMA	0x10000000	/* All allocation request will have _GFP_MOVABLE cleared */
 -#define PF_MUTEX_TESTER		0x20000000	/* Thread belongs to the rt mutex tester */
  #define PF_FREEZER_SKIP		0x40000000	/* Freezer should not count it as freezable */
  #define PF_SUSPEND_TASK		0x80000000      /* This thread called freeze_processes() and should not be frozen */
  

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2018-08-20  4:32 Stephen Rothwell
@ 2018-08-20 19:52 ` Andrew Morton
  0 siblings, 0 replies; 112+ messages in thread
From: Andrew Morton @ 2018-08-20 19:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Adrian Hunter, Arnaldo Carvalho de Melo, James Morse,
	Omar Sandoval

On Mon, 20 Aug 2018 14:32:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the akpm-current tree got conflicts in:
> 
>   fs/proc/kcore.c
>   include/linux/kcore.h
> 
> between commit:
> 
>   6855dc41b246 ("x86: Add entry trampolines to kcore")
> 
> from the tip tree and commits:
> 
>   4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list entries")
>   ea551910d3f4 ("proc/kcore: clean up ELF header generation")
>   537412a2958f ("proc/kcore: don't grab lock for kclist_add()")
> 
> from the akpm-current 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.

Yup.

What's happening here?  A two month old patch turns up in linux-next in the
middle of the merge window, in the "perf/urgent" branch.  That's a strange
branch for a June 6 patch!

Is it intended that this material be merged into 4.19-rc1?

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2018-08-20  4:32 Stephen Rothwell
  2018-08-20 19:52 ` Andrew Morton
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2018-08-20  4:32 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Adrian Hunter, Arnaldo Carvalho de Melo, James Morse,
	Omar Sandoval

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

Hi Andrew,

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

  fs/proc/kcore.c
  include/linux/kcore.h

between commit:

  6855dc41b246 ("x86: Add entry trampolines to kcore")

from the tip tree and commits:

  4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list entries")
  ea551910d3f4 ("proc/kcore: clean up ELF header generation")
  537412a2958f ("proc/kcore: don't grab lock for kclist_add()")

from the akpm-current 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 fs/proc/kcore.c
index 00282f134336,80464432dfe6..000000000000
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@@ -448,53 -291,148 +291,151 @@@ static ssize_
  read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
  {
  	char *buf = file->private_data;
- 	ssize_t acc = 0;
- 	size_t size, tsz;
- 	size_t elf_buflen;
+ 	size_t phdrs_offset, notes_offset, data_offset;
+ 	size_t phdrs_len, notes_len;
+ 	struct kcore_list *m;
+ 	size_t tsz;
  	int nphdr;
  	unsigned long start;
+ 	size_t orig_buflen = buflen;
+ 	int ret = 0;
  
- 	read_lock(&kclist_lock);
- 	size = get_kcore_size(&nphdr, &elf_buflen);
+ 	down_read(&kclist_lock);
+ 
+ 	get_kcore_size(&nphdr, &phdrs_len, &notes_len, &data_offset);
+ 	phdrs_offset = sizeof(struct elfhdr);
+ 	notes_offset = phdrs_offset + phdrs_len;
+ 
+ 	/* ELF file header. */
+ 	if (buflen && *fpos < sizeof(struct elfhdr)) {
+ 		struct elfhdr ehdr = {
+ 			.e_ident = {
+ 				[EI_MAG0] = ELFMAG0,
+ 				[EI_MAG1] = ELFMAG1,
+ 				[EI_MAG2] = ELFMAG2,
+ 				[EI_MAG3] = ELFMAG3,
+ 				[EI_CLASS] = ELF_CLASS,
+ 				[EI_DATA] = ELF_DATA,
+ 				[EI_VERSION] = EV_CURRENT,
+ 				[EI_OSABI] = ELF_OSABI,
+ 			},
+ 			.e_type = ET_CORE,
+ 			.e_machine = ELF_ARCH,
+ 			.e_version = EV_CURRENT,
+ 			.e_phoff = sizeof(struct elfhdr),
+ 			.e_flags = ELF_CORE_EFLAGS,
+ 			.e_ehsize = sizeof(struct elfhdr),
+ 			.e_phentsize = sizeof(struct elf_phdr),
+ 			.e_phnum = nphdr,
+ 		};
+ 
+ 		tsz = min_t(size_t, buflen, sizeof(struct elfhdr) - *fpos);
+ 		if (copy_to_user(buffer, (char *)&ehdr + *fpos, tsz)) {
+ 			ret = -EFAULT;
+ 			goto out;
+ 		}
  
- 	if (buflen == 0 || *fpos >= size) {
- 		read_unlock(&kclist_lock);
- 		return 0;
+ 		buffer += tsz;
+ 		buflen -= tsz;
+ 		*fpos += tsz;
  	}
  
- 	/* trim buflen to not go beyond EOF */
- 	if (buflen > size - *fpos)
- 		buflen = size - *fpos;
- 
- 	/* construct an ELF core header if we'll need some of it */
- 	if (*fpos < elf_buflen) {
- 		char * elf_buf;
- 
- 		tsz = elf_buflen - *fpos;
- 		if (buflen < tsz)
- 			tsz = buflen;
- 		elf_buf = kzalloc(elf_buflen, GFP_ATOMIC);
- 		if (!elf_buf) {
- 			read_unlock(&kclist_lock);
- 			return -ENOMEM;
+ 	/* ELF program headers. */
+ 	if (buflen && *fpos < phdrs_offset + phdrs_len) {
+ 		struct elf_phdr *phdrs, *phdr;
+ 
+ 		phdrs = kzalloc(phdrs_len, GFP_KERNEL);
+ 		if (!phdrs) {
+ 			ret = -ENOMEM;
+ 			goto out;
  		}
- 		elf_kcore_store_hdr(elf_buf, nphdr, elf_buflen);
- 		read_unlock(&kclist_lock);
- 		if (copy_to_user(buffer, elf_buf + *fpos, tsz)) {
- 			kfree(elf_buf);
- 			return -EFAULT;
+ 
+ 		phdrs[0].p_type = PT_NOTE;
+ 		phdrs[0].p_offset = notes_offset;
+ 		phdrs[0].p_filesz = notes_len;
+ 
+ 		phdr = &phdrs[1];
+ 		list_for_each_entry(m, &kclist_head, list) {
+ 			phdr->p_type = PT_LOAD;
+ 			phdr->p_flags = PF_R | PF_W | PF_X;
+ 			phdr->p_offset = kc_vaddr_to_offset(m->addr) + data_offset;
 -			phdr->p_vaddr = (size_t)m->addr;
 -			if (m->type == KCORE_RAM)
++			if (m->type == KCORE_REMAP)
++				phdr->p_vaddr	= (size_t)m->vaddr;
++			else
++				phdr->p_vaddr	= (size_t)m->addr;
++			if (m->type == KCORE_RAM || m->type == KCORE_REMAP)
+ 				phdr->p_paddr = __pa(m->addr);
+ 			else if (m->type == KCORE_TEXT)
+ 				phdr->p_paddr = __pa_symbol(m->addr);
+ 			else
+ 				phdr->p_paddr = (elf_addr_t)-1;
+ 			phdr->p_filesz = phdr->p_memsz = m->size;
+ 			phdr->p_align = PAGE_SIZE;
+ 			phdr++;
  		}
- 		kfree(elf_buf);
+ 
+ 		tsz = min_t(size_t, buflen, phdrs_offset + phdrs_len - *fpos);
+ 		if (copy_to_user(buffer, (char *)phdrs + *fpos - phdrs_offset,
+ 				 tsz)) {
+ 			kfree(phdrs);
+ 			ret = -EFAULT;
+ 			goto out;
+ 		}
+ 		kfree(phdrs);
+ 
+ 		buffer += tsz;
  		buflen -= tsz;
  		*fpos += tsz;
- 		buffer += tsz;
- 		acc += tsz;
+ 	}
+ 
+ 	/* ELF note segment. */
+ 	if (buflen && *fpos < notes_offset + notes_len) {
+ 		struct elf_prstatus prstatus = {};
+ 		struct elf_prpsinfo prpsinfo = {
+ 			.pr_sname = 'R',
+ 			.pr_fname = "vmlinux",
+ 		};
+ 		char *notes;
+ 		size_t i = 0;
+ 
+ 		strlcpy(prpsinfo.pr_psargs, saved_command_line,
+ 			sizeof(prpsinfo.pr_psargs));
+ 
+ 		notes = kzalloc(notes_len, GFP_KERNEL);
+ 		if (!notes) {
+ 			ret = -ENOMEM;
+ 			goto out;
+ 		}
+ 
+ 		append_kcore_note(notes, &i, CORE_STR, NT_PRSTATUS, &prstatus,
+ 				  sizeof(prstatus));
+ 		append_kcore_note(notes, &i, CORE_STR, NT_PRPSINFO, &prpsinfo,
+ 				  sizeof(prpsinfo));
+ 		append_kcore_note(notes, &i, CORE_STR, NT_TASKSTRUCT, current,
+ 				  arch_task_struct_size);
+ 		/*
+ 		 * vmcoreinfo_size is mostly constant after init time, but it
+ 		 * can be changed by crash_save_vmcoreinfo(). Racing here with a
+ 		 * panic on another CPU before the machine goes down is insanely
+ 		 * unlikely, but it's better to not leave potential buffer
+ 		 * overflows lying around, regardless.
+ 		 */
+ 		append_kcore_note(notes, &i, VMCOREINFO_NOTE_NAME, 0,
+ 				  vmcoreinfo_data,
+ 				  min(vmcoreinfo_size, notes_len - i));
+ 
+ 		tsz = min_t(size_t, buflen, notes_offset + notes_len - *fpos);
+ 		if (copy_to_user(buffer, notes + *fpos - notes_offset, tsz)) {
+ 			kfree(notes);
+ 			ret = -EFAULT;
+ 			goto out;
+ 		}
+ 		kfree(notes);
  
- 		/* leave now if filled buffer already */
- 		if (buflen == 0)
- 			return acc;
- 	} else
- 		read_unlock(&kclist_lock);
+ 		buffer += tsz;
+ 		buflen -= tsz;
+ 		*fpos += tsz;
+ 	}
  
  	/*
  	 * Check to see if our file offset matches with any of
diff --cc include/linux/kcore.h
index bc088ef96358,c20f296438fb..000000000000
--- a/include/linux/kcore.h
+++ b/include/linux/kcore.h
@@@ -37,13 -35,7 +37,13 @@@ struct vmcoredd_node 
  };
  
  #ifdef CONFIG_PROC_KCORE
- extern void kclist_add(struct kcore_list *, void *, size_t, int type);
+ void __init kclist_add(struct kcore_list *, void *, size_t, int type);
 +static inline
 +void kclist_add_remap(struct kcore_list *m, void *addr, void *vaddr, size_t sz)
 +{
 +	m->vaddr = (unsigned long)vaddr;
 +	kclist_add(m, addr, sz, KCORE_REMAP);
 +}
  #else
  static inline
  void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2018-03-23  5:59 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2018-03-23  5:59 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Gang He

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

Hi Andrew,

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

  fs/ocfs2/filecheck.c

between commit:

  e24e960c7fe2 ("sched/wait, fs/ocfs2: Convert wait_on_atomic_t() usage to the new wait_var_event() API")

from the tip tree and commit:

  5a5b76d17dc4 ("ocfs2: add kobject for online file check")

from the akpm-current tree.

I fixed it up (the latter removed the code updated by the former) 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 --]

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-12-18  5:04 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-12-18  5:04 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi Andrew,

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

  kernel/fork.c

between commit:

  5e28fd0b5fdb ("arch: Allow arch_dup_mmap() to fail")

from the tip tree and commit:

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

from the akpm-current 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/fork.c
index bed0eaf7233f,7fccd819866f..000000000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -391,6 -391,241 +392,240 @@@ void free_task(struct task_struct *tsk
  }
  EXPORT_SYMBOL(free_task);
  
+ #ifdef CONFIG_MMU
+ static __latent_entropy int dup_mmap(struct mm_struct *mm,
+ 					struct mm_struct *oldmm)
+ {
+ 	struct vm_area_struct *mpnt, *tmp, *prev, **pprev;
+ 	struct rb_node **rb_link, *rb_parent;
+ 	int retval;
+ 	unsigned long charge;
+ 	LIST_HEAD(uf);
+ 
+ 	uprobe_start_dup_mmap();
+ 	if (down_write_killable(&oldmm->mmap_sem)) {
+ 		retval = -EINTR;
+ 		goto fail_uprobe_end;
+ 	}
+ 	flush_cache_dup_mm(oldmm);
+ 	uprobe_dup_mmap(oldmm, mm);
+ 	/*
+ 	 * Not linked in yet - no deadlock potential:
+ 	 */
+ 	down_write_nested(&mm->mmap_sem, SINGLE_DEPTH_NESTING);
+ 
+ 	/* No ordering required: file already has been exposed. */
+ 	RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm));
+ 
+ 	mm->total_vm = oldmm->total_vm;
+ 	mm->data_vm = oldmm->data_vm;
+ 	mm->exec_vm = oldmm->exec_vm;
+ 	mm->stack_vm = oldmm->stack_vm;
+ 
+ 	rb_link = &mm->mm_rb.rb_node;
+ 	rb_parent = NULL;
+ 	pprev = &mm->mmap;
+ 	retval = ksm_fork(mm, oldmm);
+ 	if (retval)
+ 		goto out;
+ 	retval = khugepaged_fork(mm, oldmm);
+ 	if (retval)
+ 		goto out;
+ 
+ 	prev = NULL;
+ 	for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm_next) {
+ 		struct file *file;
+ 
+ 		if (mpnt->vm_flags & VM_DONTCOPY) {
+ 			vm_stat_account(mm, mpnt->vm_flags, -vma_pages(mpnt));
+ 			continue;
+ 		}
+ 		charge = 0;
+ 		if (mpnt->vm_flags & VM_ACCOUNT) {
+ 			unsigned long len = vma_pages(mpnt);
+ 
+ 			if (security_vm_enough_memory_mm(oldmm, len)) /* sic */
+ 				goto fail_nomem;
+ 			charge = len;
+ 		}
+ 		tmp = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
+ 		if (!tmp)
+ 			goto fail_nomem;
+ 		*tmp = *mpnt;
+ 		INIT_LIST_HEAD(&tmp->anon_vma_chain);
+ 		retval = vma_dup_policy(mpnt, tmp);
+ 		if (retval)
+ 			goto fail_nomem_policy;
+ 		tmp->vm_mm = mm;
+ 		retval = dup_userfaultfd(tmp, &uf);
+ 		if (retval)
+ 			goto fail_nomem_anon_vma_fork;
+ 		if (tmp->vm_flags & VM_WIPEONFORK) {
+ 			/* VM_WIPEONFORK gets a clean slate in the child. */
+ 			tmp->anon_vma = NULL;
+ 			if (anon_vma_prepare(tmp))
+ 				goto fail_nomem_anon_vma_fork;
+ 		} else if (anon_vma_fork(tmp, mpnt))
+ 			goto fail_nomem_anon_vma_fork;
+ 		tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
+ 		tmp->vm_next = tmp->vm_prev = NULL;
+ 		file = tmp->vm_file;
+ 		if (file) {
+ 			struct inode *inode = file_inode(file);
+ 			struct address_space *mapping = file->f_mapping;
+ 
+ 			get_file(file);
+ 			if (tmp->vm_flags & VM_DENYWRITE)
+ 				atomic_dec(&inode->i_writecount);
+ 			i_mmap_lock_write(mapping);
+ 			if (tmp->vm_flags & VM_SHARED)
+ 				atomic_inc(&mapping->i_mmap_writable);
+ 			flush_dcache_mmap_lock(mapping);
+ 			/* insert tmp into the share list, just after mpnt */
+ 			vma_interval_tree_insert_after(tmp, mpnt,
+ 					&mapping->i_mmap);
+ 			flush_dcache_mmap_unlock(mapping);
+ 			i_mmap_unlock_write(mapping);
+ 		}
+ 
+ 		/*
+ 		 * Clear hugetlb-related page reserves for children. This only
+ 		 * affects MAP_PRIVATE mappings. Faults generated by the child
+ 		 * are not guaranteed to succeed, even if read-only
+ 		 */
+ 		if (is_vm_hugetlb_page(tmp))
+ 			reset_vma_resv_huge_pages(tmp);
+ 
+ 		/*
+ 		 * Link in the new vma and copy the page table entries.
+ 		 */
+ 		*pprev = tmp;
+ 		pprev = &tmp->vm_next;
+ 		tmp->vm_prev = prev;
+ 		prev = tmp;
+ 
+ 		__vma_link_rb(mm, tmp, rb_link, rb_parent);
+ 		rb_link = &tmp->vm_rb.rb_right;
+ 		rb_parent = &tmp->vm_rb;
+ 
+ 		mm->map_count++;
+ 		if (!(tmp->vm_flags & VM_WIPEONFORK))
+ 			retval = copy_page_range(mm, oldmm, mpnt);
+ 
+ 		if (tmp->vm_ops && tmp->vm_ops->open)
+ 			tmp->vm_ops->open(tmp);
+ 
+ 		if (retval)
+ 			goto out;
+ 	}
+ 	/* a new mm has just been created */
 -	arch_dup_mmap(oldmm, mm);
 -	retval = 0;
++	retval = arch_dup_mmap(oldmm, mm);
+ out:
+ 	up_write(&mm->mmap_sem);
+ 	flush_tlb_mm(oldmm);
+ 	up_write(&oldmm->mmap_sem);
+ 	dup_userfaultfd_complete(&uf);
+ fail_uprobe_end:
+ 	uprobe_end_dup_mmap();
+ 	return retval;
+ fail_nomem_anon_vma_fork:
+ 	mpol_put(vma_policy(tmp));
+ fail_nomem_policy:
+ 	kmem_cache_free(vm_area_cachep, tmp);
+ fail_nomem:
+ 	retval = -ENOMEM;
+ 	vm_unacct_memory(charge);
+ 	goto out;
+ }
+ 
+ static inline int mm_alloc_pgd(struct mm_struct *mm)
+ {
+ 	mm->pgd = pgd_alloc(mm);
+ 	if (unlikely(!mm->pgd))
+ 		return -ENOMEM;
+ 	return 0;
+ }
+ 
+ static inline void mm_free_pgd(struct mm_struct *mm)
+ {
+ 	pgd_free(mm, mm->pgd);
+ }
+ #else
+ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
+ {
+ 	down_write(&oldmm->mmap_sem);
+ 	RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm));
+ 	up_write(&oldmm->mmap_sem);
+ 	return 0;
+ }
+ #define mm_alloc_pgd(mm)	(0)
+ #define mm_free_pgd(mm)
+ #endif /* CONFIG_MMU */
+ 
+ static void check_mm(struct mm_struct *mm)
+ {
+ 	int i;
+ 
+ 	for (i = 0; i < NR_MM_COUNTERS; i++) {
+ 		long x = atomic_long_read(&mm->rss_stat.count[i]);
+ 
+ 		if (unlikely(x))
+ 			printk(KERN_ALERT "BUG: Bad rss-counter state "
+ 					  "mm:%p idx:%d val:%ld\n", mm, i, x);
+ 	}
+ 
+ 	if (mm_pgtables_bytes(mm))
+ 		pr_alert("BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
+ 				mm_pgtables_bytes(mm));
+ 
+ #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
+ 	VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
+ #endif
+ }
+ 
+ #define allocate_mm()	(kmem_cache_alloc(mm_cachep, GFP_KERNEL))
+ #define free_mm(mm)	(kmem_cache_free(mm_cachep, (mm)))
+ 
+ /*
+  * Called when the last reference to the mm
+  * is dropped: either by a lazy thread or by
+  * mmput. Free the page directory and the mm.
+  */
+ static void __mmdrop(struct mm_struct *mm)
+ {
+ 	BUG_ON(mm == &init_mm);
+ 	mm_free_pgd(mm);
+ 	destroy_context(mm);
+ 	hmm_mm_destroy(mm);
+ 	mmu_notifier_mm_destroy(mm);
+ 	check_mm(mm);
+ 	put_user_ns(mm->user_ns);
+ 	free_mm(mm);
+ }
+ 
+ void mmdrop(struct mm_struct *mm)
+ {
+ 	if (unlikely(atomic_dec_and_test(&mm->mm_count)))
+ 		__mmdrop(mm);
+ }
+ EXPORT_SYMBOL_GPL(mmdrop);
+ 
+ static void mmdrop_async_fn(struct work_struct *work)
+ {
+ 	struct mm_struct *mm;
+ 
+ 	mm = container_of(work, struct mm_struct, async_put_work);
+ 	__mmdrop(mm);
+ }
+ 
+ static void mmdrop_async(struct mm_struct *mm)
+ {
+ 	if (unlikely(atomic_dec_and_test(&mm->mm_count))) {
+ 		INIT_WORK(&mm->async_put_work, mmdrop_async_fn);
+ 		schedule_work(&mm->async_put_work);
+ 	}
+ }
+ 
  static inline void free_signal_struct(struct signal_struct *sig)
  {
  	taskstats_tgid_free(sig);

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-11-10  4:33 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-11-10  4:33 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sasha Levin,
	Frederic Weisbecker

Hi Andrew,

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

  kernel/softirq.c

between commit:

  f71b74bca637 ("irq/softirqs: Use lockdep to assert IRQs are disabled/enabled")

from the tip tree and commit:

  275f9389fa4e ("kmemcheck: rip it out")

from the akpm-current tree.

I fixed it up (the latter removed code modified by the former) 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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-11-02  7:19 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-11-02  7:19 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Pavel Tatashin, Andrey Ryabinin, Kirill A. Shutemov

Hi Andrew,

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

  arch/x86/mm/kasan_init_64.c

between commit:

  12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging")

from the tip tree and commit:

  3af83426c380 ("x86/kasan: add and use kasan_map_populate()")

from the akpm-current tree.

I fixed it up (hopefully - 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/kasan_init_64.c
index fe5760db7b19,9778fec8a5dc..000000000000
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@@ -15,8 -15,73 +15,75 @@@
  
  extern struct range pfn_mapped[E820_MAX_ENTRIES];
  
 +static p4d_t tmp_p4d_table[PTRS_PER_P4D] __initdata __aligned(PAGE_SIZE);
 +
+ /* Creates mappings for kasan during early boot. The mapped memory is zeroed */
+ static int __meminit kasan_map_populate(unsigned long start, unsigned long end,
+ 					int node)
+ {
+ 	unsigned long addr, pfn, next;
+ 	unsigned long long size;
+ 	pgd_t *pgd;
+ 	p4d_t *p4d;
+ 	pud_t *pud;
+ 	pmd_t *pmd;
+ 	pte_t *pte;
+ 	int ret;
+ 
+ 	ret = vmemmap_populate(start, end, node);
+ 	/*
+ 	 * We might have partially populated memory, so check for no entries,
+ 	 * and zero only those that actually exist.
+ 	 */
+ 	for (addr = start; addr < end; addr = next) {
+ 		pgd = pgd_offset_k(addr);
+ 		if (pgd_none(*pgd)) {
+ 			next = pgd_addr_end(addr, end);
+ 			continue;
+ 		}
+ 
+ 		p4d = p4d_offset(pgd, addr);
+ 		if (p4d_none(*p4d)) {
+ 			next = p4d_addr_end(addr, end);
+ 			continue;
+ 		}
+ 
+ 		pud = pud_offset(p4d, addr);
+ 		if (pud_none(*pud)) {
+ 			next = pud_addr_end(addr, end);
+ 			continue;
+ 		}
+ 		if (pud_large(*pud)) {
+ 			/* This is PUD size page */
+ 			next = pud_addr_end(addr, end);
+ 			size = PUD_SIZE;
+ 			pfn = pud_pfn(*pud);
+ 		} else {
+ 			pmd = pmd_offset(pud, addr);
+ 			if (pmd_none(*pmd)) {
+ 				next = pmd_addr_end(addr, end);
+ 				continue;
+ 			}
+ 			if (pmd_large(*pmd)) {
+ 				/* This is PMD size page */
+ 				next = pmd_addr_end(addr, end);
+ 				size = PMD_SIZE;
+ 				pfn = pmd_pfn(*pmd);
+ 			} else {
+ 				pte = pte_offset_kernel(pmd, addr);
+ 				next = addr + PAGE_SIZE;
+ 				if (pte_none(*pte))
+ 					continue;
+ 				/* This is base size page */
+ 				size = PAGE_SIZE;
+ 				pfn = pte_pfn(*pte);
+ 			}
+ 		}
+ 		memset(phys_to_virt(PFN_PHYS(pfn)), 0, size);
+ 	}
+ 	return ret;
+ }
+ 
  static int __init map_range(struct range *range)
  {
  	unsigned long start;

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-22  6:57 Stephen Rothwell
@ 2017-08-23  6:39 ` Vlastimil Babka
  0 siblings, 0 replies; 112+ messages in thread
From: Vlastimil Babka @ 2017-08-23  6:39 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Waiman Long

On 08/22/2017 08:57 AM, Stephen Rothwell wrote:
> Hi Andrew,

Hi,

> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   init/main.c
> 
> between commit:
> 
>   caba4cbbd27d ("debugobjects: Make kmemleak ignore debug objects")
> 
> from the tip tree and commit:
> 
>   50a7dc046b58 ("mm, page_ext: move page_ext_init() after page_alloc_init_late()")

This patch can be also dropped from mmotm. It was a RFC and review
suggested a different approach which I didn't get to try yet. (The other
patches in the series should be fine to stay in any case).

> from the akpm-current 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.
> 

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-08-22  6:57 Stephen Rothwell
  2017-08-23  6:39 ` Vlastimil Babka
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2017-08-22  6:57 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Vlastimil Babka, Waiman Long

Hi Andrew,

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

  init/main.c

between commit:

  caba4cbbd27d ("debugobjects: Make kmemleak ignore debug objects")

from the tip tree and commit:

  50a7dc046b58 ("mm, page_ext: move page_ext_init() after page_alloc_init_late()")

from the akpm-current 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 init/main.c
index aea41cf8f9a3,c401e5a38af3..000000000000
--- a/init/main.c
+++ b/init/main.c
@@@ -658,9 -651,8 +659,8 @@@ asmlinkage __visible void __init start_
  		initrd_start = 0;
  	}
  #endif
- 	page_ext_init();
 -	debug_objects_mem_init();
  	kmemleak_init();
 +	debug_objects_mem_init();
  	setup_per_cpu_pageset();
  	numa_policy_init();
  	if (late_time_init)

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14 19:57                   ` Peter Zijlstra
@ 2017-08-16  4:14                     ` Minchan Kim
  0 siblings, 0 replies; 112+ messages in thread
From: Minchan Kim @ 2017-08-16  4:14 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Nadav Amit, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

On Mon, Aug 14, 2017 at 09:57:23PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 14, 2017 at 05:38:39PM +0900, Minchan Kim wrote:
> > memory-barrier.txt always scares me. I have read it for a while
> > and IIUC, it seems semantic of spin_unlock(&same_pte) would be
> > enough without some memory-barrier inside mm_tlb_flush_nested.
> 
> Indeed, see the email I just send. Its both spin_lock() and
> spin_unlock() that we care about.
> 
> Aside from the semi permeable barrier of these primitives, RCpc ensures
> these orderings only work against the _same_ lock variable.
> 
> Let me try and explain the ordering for PPC (which is by far the worst
> we have in this regard):
> 
> 
> spin_lock(lock)
> {
> 	while (test_and_set(lock))
> 		cpu_relax();
> 	lwsync();
> }
> 
> 
> spin_unlock(lock)
> {
> 	lwsync();
> 	clear(lock);
> }
> 
> Now LWSYNC has fairly 'simple' semantics, but with fairly horrible
> ramifications. Consider LWSYNC to provide _local_ TSO ordering, this
> means that it allows 'stores reordered after loads'.
> 
> For the spin_lock() that implies that all load/store's inside the lock
> do indeed stay in, but the ACQUIRE is only on the LOAD of the
> test_and_set(). That is, the actual _set_ can leak in. After all it can
> re-order stores after load (inside the lock).
> 
> For unlock it again means all load/store's prior stay prior, and the
> RELEASE is on the store clearing the lock state (nothing surprising
> here).
> 
> Now the _local_ part, the main take-away is that these orderings are
> strictly CPU local. What makes the spinlock work across CPUs (as we'd
> very much expect it to) is the address dependency on the lock variable.
> 
> In order for the spin_lock() to succeed, it must observe the clear. Its
> this link that crosses between the CPUs and builds the ordering. But
> only the two CPUs agree on this order. A third CPU not involved in
> this transaction can disagree on the order of events.

The detail explanation in your previous reply makes me comfortable
from scary memory-barrier.txt but this reply makes me scared again. ;-)

Thanks for the kind clarification, Peter!

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14 19:38                 ` Peter Zijlstra
@ 2017-08-15  7:51                   ` Nadav Amit
  0 siblings, 0 replies; 112+ messages in thread
From: Nadav Amit @ 2017-08-15  7:51 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Minchan Kim, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Aug 14, 2017 at 05:07:19AM +0000, Nadav Amit wrote:
>>>> So I'm not entirely clear about this yet.
>>>> 
>>>> How about:
>>>> 
>>>> 
>>>> 	CPU0				CPU1
>>>> 
>>>> 					tlb_gather_mmu()
>>>> 
>>>> 					lock PTLn
>>>> 					no mod
>>>> 					unlock PTLn
>>>> 
>>>> 	tlb_gather_mmu()
>>>> 
>>>> 					lock PTLm
>>>> 					mod
>>>> 					include in tlb range
>>>> 					unlock PTLm
>>>> 
>>>> 	lock PTLn
>>>> 	mod
>>>> 	unlock PTLn
>>>> 
>>>> 					tlb_finish_mmu()
>>>> 					  force = mm_tlb_flush_nested(tlb->mm);
>>>> 					  arch_tlb_finish_mmu(force);
>>>> 
>>>> 
>>>> 	... more ...
>>>> 
>>>> 	tlb_finish_mmu()
>>>> 
>>>> 
>>>> 
>>>> In this case you also want CPU1's mm_tlb_flush_nested() call to return
>>>> true, right?
>>> 
>>> No, because CPU 1 mofified pte and added it into tlb range
>>> so regardless of nested, it will flush TLB so there is no stale
>>> TLB problem.
> 
>> To clarify: the main problem that these patches address is when the first
>> CPU updates the PTE, and second CPU sees the updated value and thinks: “the
>> PTE is already what I wanted - no flush is needed”.
> 
> OK, that simplifies things.
> 
>> For some reason (I would assume intentional), all the examples here first
>> “do not modify” the PTE, and then modify it - which is not an “interesting”
>> case.
> 
> Depends on what you call 'interesting' :-) They are 'interesting' to
> make work from a memory ordering POV. And since I didn't get they were
> excluded from the set, I worried.
> 
> In fact, if they were to be included, I couldn't make it work at all. So
> I'm really glad to hear we can disregard them.
> 
>> However, based on what I understand on the memory barriers, I think
>> there is indeed a missing barrier before reading it in
>> mm_tlb_flush_nested(). IIUC using smp_mb__after_unlock_lock() in this case,
>> before reading, would solve the problem with least impact on systems with
>> strong memory ordering.
> 
> No, all is well. If, as you say, we're naturally constrained to the case
> where we only care about prior modification we can rely on the RCpc PTL
> locks.
> 
> Consider:
> 
> 
> 	CPU0				CPU1
> 
> 					tlb_gather_mmu()
> 
> 	tlb_gather_mmu()
> 	  inc	--------.
> 			| (inc is constrained by RELEASE)
> 	lock PTLn	|
> 	mod		^
> 	unlock PTLn ----------------->	lock PTLn
> 				v	no mod
> 				|	unlock PTLn
> 				|
> 				|	lock PTLm
> 				|	mod
> 				|	include in tlb range
> 				|	unlock PTLm
> 				|
> 	(read is constrained	|
> 	          by ACQUIRE)	|
> 				|	tlb_finish_mmu()
> 				`----	  force = mm_tlb_flush_nested(tlb->mm);
> 					  arch_tlb_finish_mmu(force);
> 
> 
> 	... more ...
> 
> 	tlb_finish_mmu()
> 
> 
> Then CPU1's acquire of PTLn orders against CPU0's release of that same
> PTLn which guarantees we observe both its (prior) modified PTE and the
> mm->tlb_flush_pending increment from tlb_gather_mmu().
> 
> So all we need for mm_tlb_flush_nested() to work is having acquired the
> right PTL at least once before calling it.
> 
> At the same time, the decrements need to be after the TLB invalidate is
> complete, this ensures that _IF_ we observe the decrement, we must've
> also observed the corresponding invalidate.
> 
> Something like the below is then sufficient.
> 
> ---
> Subject: mm: Clarify tlb_flush_pending barriers
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Fri, 11 Aug 2017 16:04:50 +0200
> 
> Better document the ordering around tlb_flush_pending.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> include/linux/mm_types.h |   78 +++++++++++++++++++++++++++--------------------
> 1 file changed, 45 insertions(+), 33 deletions(-)
> 
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -526,30 +526,6 @@ extern void tlb_gather_mmu(struct mmu_ga
> extern void tlb_finish_mmu(struct mmu_gather *tlb,
> 				unsigned long start, unsigned long end);
> 
> -/*
> - * Memory barriers to keep this state in sync are graciously provided by
> - * the page table locks, outside of which no page table modifications happen.
> - * The barriers are used to ensure the order between tlb_flush_pending updates,
> - * which happen while the lock is not taken, and the PTE updates, which happen
> - * while the lock is taken, are serialized.
> - */
> -static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
> -{
> -	/*
> -	 * Must be called with PTL held; such that our PTL acquire will have
> -	 * observed the store from set_tlb_flush_pending().
> -	 */
> -	return atomic_read(&mm->tlb_flush_pending) > 0;
> -}
> -
> -/*
> - * Returns true if there are two above TLB batching threads in parallel.
> - */
> -static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
> -{
> -	return atomic_read(&mm->tlb_flush_pending) > 1;
> -}
> -
> static inline void init_tlb_flush_pending(struct mm_struct *mm)
> {
> 	atomic_set(&mm->tlb_flush_pending, 0);
> @@ -558,7 +534,6 @@ static inline void init_tlb_flush_pendin
> static inline void inc_tlb_flush_pending(struct mm_struct *mm)
> {
> 	atomic_inc(&mm->tlb_flush_pending);
> -
> 	/*
> 	 * The only time this value is relevant is when there are indeed pages
> 	 * to flush. And we'll only flush pages after changing them, which
> @@ -580,24 +555,61 @@ static inline void inc_tlb_flush_pending
> 	 *	flush_tlb_range();
> 	 *	atomic_dec(&mm->tlb_flush_pending);
> 	 *
> -	 * So the =true store is constrained by the PTL unlock, and the =false
> -	 * store is constrained by the TLB invalidate.
> +	 * Where the increment if constrained by the PTL unlock, it thus
> +	 * ensures that the increment is visible if the PTE modification is
> +	 * visible. After all, if there is no PTE modification, nobody cares
> +	 * about TLB flushes either.
> +	 *
> +	 * This very much relies on users (mm_tlb_flush_pending() and
> +	 * mm_tlb_flush_nested()) only caring about _specific_ PTEs (and
> +	 * therefore specific PTLs), because with SPLIT_PTE_PTLOCKS and RCpc
> +	 * locks (PPC) the unlock of one doesn't order against the lock of
> +	 * another PTL.
> +	 *
> +	 * The decrement is ordered by the flush_tlb_range(), such that
> +	 * mm_tlb_flush_pending() will not return false unless all flushes have
> +	 * completed.
> 	 */
> }
> 
> -/* Clearing is done after a TLB flush, which also provides a barrier. */
> static inline void dec_tlb_flush_pending(struct mm_struct *mm)
> {
> 	/*
> -	 * Guarantee that the tlb_flush_pending does not not leak into the
> -	 * critical section, since we must order the PTE change and changes to
> -	 * the pending TLB flush indication. We could have relied on TLB flush
> -	 * as a memory barrier, but this behavior is not clearly documented.
> +	 * See inc_tlb_flush_pending().
> +	 *
> +	 * This cannot be smp_mb__before_atomic() because smp_mb() simply does
> +	 * not order against TLB invalidate completion, which is what we need.
> +	 *
> +	 * Therefore we must rely on tlb_flush_*() to guarantee order.
> 	 */
> -	smp_mb__before_atomic();
> 	atomic_dec(&mm->tlb_flush_pending);
> }
> 
> +static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
> +{
> +	/*
> +	 * Must be called after having acquired the PTL; orders against that
> +	 * PTLs release and therefore ensures that if we observe the modified
> +	 * PTE we must also observe the increment from inc_tlb_flush_pending().
> +	 *
> +	 * That is, it only guarantees to return true if there is a flush
> +	 * pending for _this_ PTL.
> +	 */
> +	return atomic_read(&mm->tlb_flush_pending);
> +}
> +
> +static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
> +{
> +	/*
> +	 * Similar to mm_tlb_flush_pending(), we must have acquired the PTL
> +	 * for which there is a TLB flush pending in order to guarantee
> +	 * we've seen both that PTE modification and the increment.
> +	 *
> +	 * (no requirement on actually still holding the PTL, that is irrelevant)
> +	 */
> +	return atomic_read(&mm->tlb_flush_pending) > 1;
> +}
> +
> struct vm_fault;
> 
> struct vm_special_mapping {

Thanks for the detailed explanation. I will pay more attention next time.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  8:38                 ` Minchan Kim
@ 2017-08-14 19:57                   ` Peter Zijlstra
  2017-08-16  4:14                     ` Minchan Kim
  0 siblings, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-14 19:57 UTC (permalink / raw)
  To: Minchan Kim
  Cc: Nadav Amit, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

On Mon, Aug 14, 2017 at 05:38:39PM +0900, Minchan Kim wrote:
> memory-barrier.txt always scares me. I have read it for a while
> and IIUC, it seems semantic of spin_unlock(&same_pte) would be
> enough without some memory-barrier inside mm_tlb_flush_nested.

Indeed, see the email I just send. Its both spin_lock() and
spin_unlock() that we care about.

Aside from the semi permeable barrier of these primitives, RCpc ensures
these orderings only work against the _same_ lock variable.

Let me try and explain the ordering for PPC (which is by far the worst
we have in this regard):


spin_lock(lock)
{
	while (test_and_set(lock))
		cpu_relax();
	lwsync();
}


spin_unlock(lock)
{
	lwsync();
	clear(lock);
}

Now LWSYNC has fairly 'simple' semantics, but with fairly horrible
ramifications. Consider LWSYNC to provide _local_ TSO ordering, this
means that it allows 'stores reordered after loads'.

For the spin_lock() that implies that all load/store's inside the lock
do indeed stay in, but the ACQUIRE is only on the LOAD of the
test_and_set(). That is, the actual _set_ can leak in. After all it can
re-order stores after load (inside the lock).

For unlock it again means all load/store's prior stay prior, and the
RELEASE is on the store clearing the lock state (nothing surprising
here).

Now the _local_ part, the main take-away is that these orderings are
strictly CPU local. What makes the spinlock work across CPUs (as we'd
very much expect it to) is the address dependency on the lock variable.

In order for the spin_lock() to succeed, it must observe the clear. Its
this link that crosses between the CPUs and builds the ordering. But
only the two CPUs agree on this order. A third CPU not involved in
this transaction can disagree on the order of events.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  5:07               ` Nadav Amit
  2017-08-14  5:23                 ` Minchan Kim
  2017-08-14  8:38                 ` Minchan Kim
@ 2017-08-14 19:38                 ` Peter Zijlstra
  2017-08-15  7:51                   ` Nadav Amit
  2 siblings, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-14 19:38 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Minchan Kim, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

On Mon, Aug 14, 2017 at 05:07:19AM +0000, Nadav Amit wrote:
> >> So I'm not entirely clear about this yet.
> >> 
> >> How about:
> >> 
> >> 
> >> 	CPU0				CPU1
> >> 
> >> 					tlb_gather_mmu()
> >> 
> >> 					lock PTLn
> >> 					no mod
> >> 					unlock PTLn
> >> 
> >> 	tlb_gather_mmu()
> >> 
> >> 					lock PTLm
> >> 					mod
> >> 					include in tlb range
> >> 					unlock PTLm
> >> 
> >> 	lock PTLn
> >> 	mod
> >> 	unlock PTLn
> >> 
> >> 					tlb_finish_mmu()
> >> 					  force = mm_tlb_flush_nested(tlb->mm);
> >> 					  arch_tlb_finish_mmu(force);
> >> 
> >> 
> >> 	... more ...
> >> 
> >> 	tlb_finish_mmu()
> >> 
> >> 
> >> 
> >> In this case you also want CPU1's mm_tlb_flush_nested() call to return
> >> true, right?
> > 
> > No, because CPU 1 mofified pte and added it into tlb range
> > so regardless of nested, it will flush TLB so there is no stale
> > TLB problem.

> To clarify: the main problem that these patches address is when the first
> CPU updates the PTE, and second CPU sees the updated value and thinks: “the
> PTE is already what I wanted - no flush is needed”.

OK, that simplifies things.

> For some reason (I would assume intentional), all the examples here first
> “do not modify” the PTE, and then modify it - which is not an “interesting”
> case.

Depends on what you call 'interesting' :-) They are 'interesting' to
make work from a memory ordering POV. And since I didn't get they were
excluded from the set, I worried.

In fact, if they were to be included, I couldn't make it work at all. So
I'm really glad to hear we can disregard them.

> However, based on what I understand on the memory barriers, I think
> there is indeed a missing barrier before reading it in
> mm_tlb_flush_nested(). IIUC using smp_mb__after_unlock_lock() in this case,
> before reading, would solve the problem with least impact on systems with
> strong memory ordering.

No, all is well. If, as you say, we're naturally constrained to the case
where we only care about prior modification we can rely on the RCpc PTL
locks.

Consider:


	CPU0				CPU1

					tlb_gather_mmu()

	tlb_gather_mmu()
	  inc	--------.
			| (inc is constrained by RELEASE)
	lock PTLn	|
	mod		^
	unlock PTLn ----------------->	lock PTLn
				v	no mod
				|	unlock PTLn
				|
				|	lock PTLm
				|	mod
				|	include in tlb range
				|	unlock PTLm
				|
	(read is constrained	|
	          by ACQUIRE)	|
				|	tlb_finish_mmu()
				`----	  force = mm_tlb_flush_nested(tlb->mm);
					  arch_tlb_finish_mmu(force);


	... more ...

	tlb_finish_mmu()


Then CPU1's acquire of PTLn orders against CPU0's release of that same
PTLn which guarantees we observe both its (prior) modified PTE and the
mm->tlb_flush_pending increment from tlb_gather_mmu().

So all we need for mm_tlb_flush_nested() to work is having acquired the
right PTL at least once before calling it.

At the same time, the decrements need to be after the TLB invalidate is
complete, this ensures that _IF_ we observe the decrement, we must've
also observed the corresponding invalidate.

Something like the below is then sufficient.

---
Subject: mm: Clarify tlb_flush_pending barriers
From: Peter Zijlstra <peterz@infradead.org>
Date: Fri, 11 Aug 2017 16:04:50 +0200

Better document the ordering around tlb_flush_pending.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 include/linux/mm_types.h |   78 +++++++++++++++++++++++++++--------------------
 1 file changed, 45 insertions(+), 33 deletions(-)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -526,30 +526,6 @@ extern void tlb_gather_mmu(struct mmu_ga
 extern void tlb_finish_mmu(struct mmu_gather *tlb,
 				unsigned long start, unsigned long end);
 
-/*
- * Memory barriers to keep this state in sync are graciously provided by
- * the page table locks, outside of which no page table modifications happen.
- * The barriers are used to ensure the order between tlb_flush_pending updates,
- * which happen while the lock is not taken, and the PTE updates, which happen
- * while the lock is taken, are serialized.
- */
-static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
-{
-	/*
-	 * Must be called with PTL held; such that our PTL acquire will have
-	 * observed the store from set_tlb_flush_pending().
-	 */
-	return atomic_read(&mm->tlb_flush_pending) > 0;
-}
-
-/*
- * Returns true if there are two above TLB batching threads in parallel.
- */
-static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
-{
-	return atomic_read(&mm->tlb_flush_pending) > 1;
-}
-
 static inline void init_tlb_flush_pending(struct mm_struct *mm)
 {
 	atomic_set(&mm->tlb_flush_pending, 0);
@@ -558,7 +534,6 @@ static inline void init_tlb_flush_pendin
 static inline void inc_tlb_flush_pending(struct mm_struct *mm)
 {
 	atomic_inc(&mm->tlb_flush_pending);
-
 	/*
 	 * The only time this value is relevant is when there are indeed pages
 	 * to flush. And we'll only flush pages after changing them, which
@@ -580,24 +555,61 @@ static inline void inc_tlb_flush_pending
 	 *	flush_tlb_range();
 	 *	atomic_dec(&mm->tlb_flush_pending);
 	 *
-	 * So the =true store is constrained by the PTL unlock, and the =false
-	 * store is constrained by the TLB invalidate.
+	 * Where the increment if constrained by the PTL unlock, it thus
+	 * ensures that the increment is visible if the PTE modification is
+	 * visible. After all, if there is no PTE modification, nobody cares
+	 * about TLB flushes either.
+	 *
+	 * This very much relies on users (mm_tlb_flush_pending() and
+	 * mm_tlb_flush_nested()) only caring about _specific_ PTEs (and
+	 * therefore specific PTLs), because with SPLIT_PTE_PTLOCKS and RCpc
+	 * locks (PPC) the unlock of one doesn't order against the lock of
+	 * another PTL.
+	 *
+	 * The decrement is ordered by the flush_tlb_range(), such that
+	 * mm_tlb_flush_pending() will not return false unless all flushes have
+	 * completed.
 	 */
 }
 
-/* Clearing is done after a TLB flush, which also provides a barrier. */
 static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 	/*
-	 * Guarantee that the tlb_flush_pending does not not leak into the
-	 * critical section, since we must order the PTE change and changes to
-	 * the pending TLB flush indication. We could have relied on TLB flush
-	 * as a memory barrier, but this behavior is not clearly documented.
+	 * See inc_tlb_flush_pending().
+	 *
+	 * This cannot be smp_mb__before_atomic() because smp_mb() simply does
+	 * not order against TLB invalidate completion, which is what we need.
+	 *
+	 * Therefore we must rely on tlb_flush_*() to guarantee order.
 	 */
-	smp_mb__before_atomic();
 	atomic_dec(&mm->tlb_flush_pending);
 }
 
+static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
+{
+	/*
+	 * Must be called after having acquired the PTL; orders against that
+	 * PTLs release and therefore ensures that if we observe the modified
+	 * PTE we must also observe the increment from inc_tlb_flush_pending().
+	 *
+	 * That is, it only guarantees to return true if there is a flush
+	 * pending for _this_ PTL.
+	 */
+	return atomic_read(&mm->tlb_flush_pending);
+}
+
+static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
+{
+	/*
+	 * Similar to mm_tlb_flush_pending(), we must have acquired the PTL
+	 * for which there is a TLB flush pending in order to guarantee
+	 * we've seen both that PTE modification and the increment.
+	 *
+	 * (no requirement on actually still holding the PTL, that is irrelevant)
+	 */
+	return atomic_read(&mm->tlb_flush_pending) > 1;
+}
+
 struct vm_fault;
 
 struct vm_special_mapping {

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  3:09         ` Minchan Kim
@ 2017-08-14 18:54           ` Peter Zijlstra
  0 siblings, 0 replies; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-14 18:54 UTC (permalink / raw)
  To: Minchan Kim
  Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus

On Mon, Aug 14, 2017 at 12:09:14PM +0900, Minchan Kim wrote:
> @@ -446,9 +450,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
>  	 *
>  	 */
>  	bool force = mm_tlb_flush_nested(tlb->mm);
> -
>  	arch_tlb_finish_mmu(tlb, start, end, force);
> -	dec_tlb_flush_pending(tlb->mm);
>  }

No, I think this breaks all the mm_tlb_flush_pending() users. They need
the decrement to not be visible until the TLB flush is complete.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  5:07               ` Nadav Amit
  2017-08-14  5:23                 ` Minchan Kim
@ 2017-08-14  8:38                 ` Minchan Kim
  2017-08-14 19:57                   ` Peter Zijlstra
  2017-08-14 19:38                 ` Peter Zijlstra
  2 siblings, 1 reply; 112+ messages in thread
From: Minchan Kim @ 2017-08-14  8:38 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Peter Zijlstra, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

Hi Nadav,

On Mon, Aug 14, 2017 at 05:07:19AM +0000, Nadav Amit wrote:
< snip >

> For some reason (I would assume intentional), all the examples here first
> “do not modify” the PTE, and then modify it - which is not an “interesting”
> case. However, based on what I understand on the memory barriers, I think
> there is indeed a missing barrier before reading it in
> mm_tlb_flush_nested(). IIUC using smp_mb__after_unlock_lock() in this case,

memory-barrier.txt always scares me. I have read it for a while
and IIUC, it seems semantic of spin_unlock(&same_pte) would be
enough without some memory-barrier inside mm_tlb_flush_nested.

I would be missing something totally.

Could you explain what kinds of sequence you have in mind to
have such problem?

Thanks.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  5:07               ` Nadav Amit
@ 2017-08-14  5:23                 ` Minchan Kim
  2017-08-14  8:38                 ` Minchan Kim
  2017-08-14 19:38                 ` Peter Zijlstra
  2 siblings, 0 replies; 112+ messages in thread
From: Minchan Kim @ 2017-08-14  5:23 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Peter Zijlstra, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

On Mon, Aug 14, 2017 at 05:07:19AM +0000, Nadav Amit wrote:
< snip >

> Minchan, as for the solution you proposed, it seems to open again a race,
> since the “pending” indication is removed before the actual TLB flush is
> performed.

Oops, you're right!

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-14  3:16             ` Minchan Kim
@ 2017-08-14  5:07               ` Nadav Amit
  2017-08-14  5:23                 ` Minchan Kim
                                   ` (2 more replies)
  0 siblings, 3 replies; 112+ messages in thread
From: Nadav Amit @ 2017-08-14  5:07 UTC (permalink / raw)
  To: Minchan Kim
  Cc: Peter Zijlstra, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

Minchan Kim <minchan@kernel.org> wrote:

> On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote:
>> On Sun, Aug 13, 2017 at 06:06:32AM +0000, Nadav Amit wrote:
>>>> however mm_tlb_flush_nested() is a mystery, it appears to care about
>>>> anything inside the range. For now rely on it doing at least _a_ PTL
>>>> lock instead of taking  _the_ PTL lock.
>>> 
>>> It does not care about “anything” inside the range, but only on situations
>>> in which there is at least one (same) PT that was modified by one core and
>>> then read by the other. So, yes, it will always be _the_ same PTL, and not
>>> _a_ PTL - in the cases that flush is really needed.
>>> 
>>> The issue that might require additional barriers is that
>>> inc_tlb_flush_pending() and mm_tlb_flush_nested() are called when the PTL is
>>> not held. IIUC, since the release-acquire might not behave as a full memory
>>> barrier, this requires an explicit memory barrier.
>> 
>> So I'm not entirely clear about this yet.
>> 
>> How about:
>> 
>> 
>> 	CPU0				CPU1
>> 
>> 					tlb_gather_mmu()
>> 
>> 					lock PTLn
>> 					no mod
>> 					unlock PTLn
>> 
>> 	tlb_gather_mmu()
>> 
>> 					lock PTLm
>> 					mod
>> 					include in tlb range
>> 					unlock PTLm
>> 
>> 	lock PTLn
>> 	mod
>> 	unlock PTLn
>> 
>> 					tlb_finish_mmu()
>> 					  force = mm_tlb_flush_nested(tlb->mm);
>> 					  arch_tlb_finish_mmu(force);
>> 
>> 
>> 	... more ...
>> 
>> 	tlb_finish_mmu()
>> 
>> 
>> 
>> In this case you also want CPU1's mm_tlb_flush_nested() call to return
>> true, right?
> 
> No, because CPU 1 mofified pte and added it into tlb range
> so regardless of nested, it will flush TLB so there is no stale
> TLB problem.
> 
>> But even with an smp_mb__after_atomic() at CPU0's tlg_bather_mmu()
>> you're not guaranteed CPU1 sees the increment. The only way to do that
>> is to make the PTL locks RCsc and that is a much more expensive
>> proposition.
>> 
>> 
>> What about:
>> 
>> 
>> 	CPU0				CPU1
>> 
>> 					tlb_gather_mmu()
>> 
>> 					lock PTLn
>> 					no mod
>> 					unlock PTLn
>> 
>> 
>> 					lock PTLm
>> 					mod
>> 					include in tlb range
>> 					unlock PTLm
>> 
>> 	tlb_gather_mmu()
>> 
>> 	lock PTLn
>> 	mod
>> 	unlock PTLn
>> 
>> 					tlb_finish_mmu()
>> 					  force = mm_tlb_flush_nested(tlb->mm);
>> 					  arch_tlb_finish_mmu(force);
>> 
>> 
>> 	... more ...
>> 
>> 	tlb_finish_mmu()
>> 
>> Do we want CPU1 to see it here? If so, where does it end?
> 
> Ditto. Since CPU 1 has added range, it will flush TLB regardless
> of nested condition.
> 
>> CPU0				CPU1
>> 
>> 					tlb_gather_mmu()
>> 
>> 					lock PTLn
>> 					no mod
>> 					unlock PTLn
>> 
>> 
>> 					lock PTLm
>> 					mod
>> 					include in tlb range
>> 					unlock PTLm
>> 
>> 					tlb_finish_mmu()
>> 					  force = mm_tlb_flush_nested(tlb->mm);
>> 
>> 	tlb_gather_mmu()
>> 
>> 	lock PTLn
>> 	mod
>> 	unlock PTLn
>> 
>> 					  arch_tlb_finish_mmu(force);
>> 
>> 
>> 	... more ...
>> 
>> 	tlb_finish_mmu()
>> 
>> 
>> This?
>> 
>> 
>> Could you clarify under what exact condition mm_tlb_flush_nested() must
>> return true?
> 
> mm_tlb_flush_nested aims for the CPU side where there is no pte update
> but need TLB flush.
> As I wrote https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dmm-26m-3D150267398226529-26w-3D2&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=x9zhXCtCLvTDtvE65-BGSA&m=v2Z7eDi7z1H9zdngcjZvlNeBudWzA9KvcXFNpU2A77s&s=amaSu_gurmBHHPcl3Pxfdl0Tk_uTnmf60tMQAsNDHVU&e= ,
> it has stable TLB problem if we don't flush TLB although there is no
> pte modification.

To clarify: the main problem that these patches address is when the first
CPU updates the PTE, and second CPU sees the updated value and thinks: “the
PTE is already what I wanted - no flush is needed”.

For some reason (I would assume intentional), all the examples here first
“do not modify” the PTE, and then modify it - which is not an “interesting”
case. However, based on what I understand on the memory barriers, I think
there is indeed a missing barrier before reading it in
mm_tlb_flush_nested(). IIUC using smp_mb__after_unlock_lock() in this case,
before reading, would solve the problem with least impact on systems with
strong memory ordering.

Minchan, as for the solution you proposed, it seems to open again a race,
since the “pending” indication is removed before the actual TLB flush is
performed.

Nadav

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-13 12:50           ` Peter Zijlstra
@ 2017-08-14  3:16             ` Minchan Kim
  2017-08-14  5:07               ` Nadav Amit
  0 siblings, 1 reply; 112+ messages in thread
From: Minchan Kim @ 2017-08-14  3:16 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Nadav Amit, Ingo Molnar, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Linus

On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote:
> On Sun, Aug 13, 2017 at 06:06:32AM +0000, Nadav Amit wrote:
> > > however mm_tlb_flush_nested() is a mystery, it appears to care about
> > > anything inside the range. For now rely on it doing at least _a_ PTL
> > > lock instead of taking  _the_ PTL lock.
> > 
> > It does not care about “anything” inside the range, but only on situations
> > in which there is at least one (same) PT that was modified by one core and
> > then read by the other. So, yes, it will always be _the_ same PTL, and not
> > _a_ PTL - in the cases that flush is really needed.
> > 
> > The issue that might require additional barriers is that
> > inc_tlb_flush_pending() and mm_tlb_flush_nested() are called when the PTL is
> > not held. IIUC, since the release-acquire might not behave as a full memory
> > barrier, this requires an explicit memory barrier.
> 
> So I'm not entirely clear about this yet.
> 
> How about:
> 
> 
> 	CPU0				CPU1
> 
> 					tlb_gather_mmu()
> 
> 					lock PTLn
> 					no mod
> 					unlock PTLn
> 
> 	tlb_gather_mmu()
> 
> 					lock PTLm
> 					mod
> 					include in tlb range
> 					unlock PTLm
> 
> 	lock PTLn
> 	mod
> 	unlock PTLn
> 
> 					tlb_finish_mmu()
> 					  force = mm_tlb_flush_nested(tlb->mm);
> 					  arch_tlb_finish_mmu(force);
> 
> 
> 	... more ...
> 
> 	tlb_finish_mmu()
> 
> 
> 
> In this case you also want CPU1's mm_tlb_flush_nested() call to return
> true, right?

No, because CPU 1 mofified pte and added it into tlb range
so regardless of nested, it will flush TLB so there is no stale
TLB problem.

> 
> But even with an smp_mb__after_atomic() at CPU0's tlg_bather_mmu()
> you're not guaranteed CPU1 sees the increment. The only way to do that
> is to make the PTL locks RCsc and that is a much more expensive
> proposition.
> 
> 
> What about:
> 
> 
> 	CPU0				CPU1
> 
> 					tlb_gather_mmu()
> 
> 					lock PTLn
> 					no mod
> 					unlock PTLn
> 
> 
> 					lock PTLm
> 					mod
> 					include in tlb range
> 					unlock PTLm
> 
> 	tlb_gather_mmu()
> 
> 	lock PTLn
> 	mod
> 	unlock PTLn
> 
> 					tlb_finish_mmu()
> 					  force = mm_tlb_flush_nested(tlb->mm);
> 					  arch_tlb_finish_mmu(force);
> 
> 
> 	... more ...
> 
> 	tlb_finish_mmu()
> 
> Do we want CPU1 to see it here? If so, where does it end?

Ditto. Since CPU 1 has added range, it will flush TLB regardless
of nested condition.

> 
> 	CPU0				CPU1
> 
> 					tlb_gather_mmu()
> 
> 					lock PTLn
> 					no mod
> 					unlock PTLn
> 
> 
> 					lock PTLm
> 					mod
> 					include in tlb range
> 					unlock PTLm
> 
> 					tlb_finish_mmu()
> 					  force = mm_tlb_flush_nested(tlb->mm);
> 
> 	tlb_gather_mmu()
> 
> 	lock PTLn
> 	mod
> 	unlock PTLn
> 
> 					  arch_tlb_finish_mmu(force);
> 
> 
> 	... more ...
> 
> 	tlb_finish_mmu()
> 
> 
> This?
> 
> 
> Could you clarify under what exact condition mm_tlb_flush_nested() must
> return true?

mm_tlb_flush_nested aims for the CPU side where there is no pte update
but need TLB flush.
As I wrote https://marc.info/?l=linux-mm&m=150267398226529&w=2,
it has stable TLB problem if we don't flush TLB although there is no
pte modification.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 14:04       ` Peter Zijlstra
  2017-08-13  6:06         ` Nadav Amit
@ 2017-08-14  3:09         ` Minchan Kim
  2017-08-14 18:54           ` Peter Zijlstra
  1 sibling, 1 reply; 112+ messages in thread
From: Minchan Kim @ 2017-08-14  3:09 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus

Hi Peter,

On Fri, Aug 11, 2017 at 04:04:50PM +0200, Peter Zijlstra wrote:
> 
> Ok, so I have the below to still go on-top.
> 
> Ideally someone would clarify the situation around
> mm_tlb_flush_nested(), because ideally we'd remove the
> smp_mb__after_atomic() and go back to relying on PTL alone.
> 
> This also removes the pointless smp_mb__before_atomic()

I'm not an expert of barrier stuff but IIUC, mm_tlb_flush_nested's
side full memory barrier can go with removing smp_mb__after_atomic
in inc_tlb_flush_pending side?


diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 490af494c2da..5ad0e66df363 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -544,7 +544,12 @@ static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
  */
 static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
 {
-	return atomic_read(&mm->tlb_flush_pending) > 1;
+	/*
+	 * atomic_dec_and_test's full memory barrier guarantees
+	 * to see uptodate tlb_flush_pending count in other CPU
+	 * without relying on page table lock.
+	 */
+	return !atomic_dec_and_test(&mm->tlb_flush_pending);
 }
 
 static inline void init_tlb_flush_pending(struct mm_struct *mm)
diff --git a/mm/memory.c b/mm/memory.c
index f571b0eb9816..e90b57bc65fb 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -407,6 +407,10 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
 			unsigned long start, unsigned long end)
 {
 	arch_tlb_gather_mmu(tlb, mm, start, end);
+	/*
+	 * couterpart is mm_tlb_flush_nested in tlb_finish_mmu
+	 * which decreases pending count.
+	 */
 	inc_tlb_flush_pending(tlb->mm);
 }
 
@@ -446,9 +450,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
 	 *
 	 */
 	bool force = mm_tlb_flush_nested(tlb->mm);
-
 	arch_tlb_finish_mmu(tlb, start, end, force);
-	dec_tlb_flush_pending(tlb->mm);
 }
 
 /*

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-13  6:06         ` Nadav Amit
@ 2017-08-13 12:50           ` Peter Zijlstra
  2017-08-14  3:16             ` Minchan Kim
  0 siblings, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-13 12:50 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Linus, minchan

On Sun, Aug 13, 2017 at 06:06:32AM +0000, Nadav Amit wrote:
> > however mm_tlb_flush_nested() is a mystery, it appears to care about
> > anything inside the range. For now rely on it doing at least _a_ PTL
> > lock instead of taking  _the_ PTL lock.
> 
> It does not care about “anything” inside the range, but only on situations
> in which there is at least one (same) PT that was modified by one core and
> then read by the other. So, yes, it will always be _the_ same PTL, and not
> _a_ PTL - in the cases that flush is really needed.
> 
> The issue that might require additional barriers is that
> inc_tlb_flush_pending() and mm_tlb_flush_nested() are called when the PTL is
> not held. IIUC, since the release-acquire might not behave as a full memory
> barrier, this requires an explicit memory barrier.

So I'm not entirely clear about this yet.

How about:


	CPU0				CPU1

					tlb_gather_mmu()

					lock PTLn
					no mod
					unlock PTLn

	tlb_gather_mmu()

					lock PTLm
					mod
					include in tlb range
					unlock PTLm

	lock PTLn
	mod
	unlock PTLn

					tlb_finish_mmu()
					  force = mm_tlb_flush_nested(tlb->mm);
					  arch_tlb_finish_mmu(force);


	... more ...

	tlb_finish_mmu()



In this case you also want CPU1's mm_tlb_flush_nested() call to return
true, right?

But even with an smp_mb__after_atomic() at CPU0's tlg_bather_mmu()
you're not guaranteed CPU1 sees the increment. The only way to do that
is to make the PTL locks RCsc and that is a much more expensive
proposition.


What about:


	CPU0				CPU1

					tlb_gather_mmu()

					lock PTLn
					no mod
					unlock PTLn


					lock PTLm
					mod
					include in tlb range
					unlock PTLm

	tlb_gather_mmu()

	lock PTLn
	mod
	unlock PTLn

					tlb_finish_mmu()
					  force = mm_tlb_flush_nested(tlb->mm);
					  arch_tlb_finish_mmu(force);


	... more ...

	tlb_finish_mmu()

Do we want CPU1 to see it here? If so, where does it end?


	CPU0				CPU1

					tlb_gather_mmu()

					lock PTLn
					no mod
					unlock PTLn


					lock PTLm
					mod
					include in tlb range
					unlock PTLm

					tlb_finish_mmu()
					  force = mm_tlb_flush_nested(tlb->mm);

	tlb_gather_mmu()

	lock PTLn
	mod
	unlock PTLn

					  arch_tlb_finish_mmu(force);


	... more ...

	tlb_finish_mmu()


This?


Could you clarify under what exact condition mm_tlb_flush_nested() must
return true?

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 14:04       ` Peter Zijlstra
@ 2017-08-13  6:06         ` Nadav Amit
  2017-08-13 12:50           ` Peter Zijlstra
  2017-08-14  3:09         ` Minchan Kim
  1 sibling, 1 reply; 112+ messages in thread
From: Nadav Amit @ 2017-08-13  6:06 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Linus, minchan

Peter Zijlstra <peterz@infradead.org> wrote:

> 
> Ok, so I have the below to still go on-top.
> 
> Ideally someone would clarify the situation around
> mm_tlb_flush_nested(), because ideally we'd remove the
> smp_mb__after_atomic() and go back to relying on PTL alone.
> 
> This also removes the pointless smp_mb__before_atomic()
> 
> ---
> Subject: mm: Fix barriers for the tlb_flush_pending thing
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Fri Aug 11 12:43:33 CEST 2017
> 
> I'm not 100% sure we always care about the same PTL and when we have
> SPLIT_PTE_PTLOCKS and have RCpc locks (PPC) the UNLOCK of one does not
> in fact order against the LOCK of another lock. Therefore the
> documented scheme does not work if we care about multiple PTLs
> 
> mm_tlb_flush_pending() appears to only care about a single PTL:
> 
> - arch pte_accessible() (x86, arm64) only cares about that one PTE.
> - do_huge_pmd_numa_page() also only cares about a single (huge) page.
> - ksm write_protect_page() also only cares about a single page.
> 
> however mm_tlb_flush_nested() is a mystery, it appears to care about
> anything inside the range. For now rely on it doing at least _a_ PTL
> lock instead of taking  _the_ PTL lock.

It does not care about “anything” inside the range, but only on situations
in which there is at least one (same) PT that was modified by one core and
then read by the other. So, yes, it will always be _the_ same PTL, and not
_a_ PTL - in the cases that flush is really needed.

The issue that might require additional barriers is that
inc_tlb_flush_pending() and mm_tlb_flush_nested() are called when the PTL is
not held. IIUC, since the release-acquire might not behave as a full memory
barrier, this requires an explicit memory barrier.

> Therefore add an explicit smp_mb__after_atomic() to cure things.
> 
> Also remove the smp_mb__before_atomic() on the dec side, as its
> completely pointless. We must rely on flush_tlb_range() to DTRT.

Good. It seemed fishy to me, but I was focused on the TLB consistency and
less on the barriers (that’s my excuse).

Nadav

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 11:56     ` Ingo Molnar
  2017-08-11 12:17       ` Peter Zijlstra
@ 2017-08-11 14:04       ` Peter Zijlstra
  2017-08-13  6:06         ` Nadav Amit
  2017-08-14  3:09         ` Minchan Kim
  1 sibling, 2 replies; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-11 14:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus, minchan


Ok, so I have the below to still go on-top.

Ideally someone would clarify the situation around
mm_tlb_flush_nested(), because ideally we'd remove the
smp_mb__after_atomic() and go back to relying on PTL alone.

This also removes the pointless smp_mb__before_atomic()

---
Subject: mm: Fix barriers for the tlb_flush_pending thing
From: Peter Zijlstra <peterz@infradead.org>
Date: Fri Aug 11 12:43:33 CEST 2017

I'm not 100% sure we always care about the same PTL and when we have
SPLIT_PTE_PTLOCKS and have RCpc locks (PPC) the UNLOCK of one does not
in fact order against the LOCK of another lock. Therefore the
documented scheme does not work if we care about multiple PTLs

mm_tlb_flush_pending() appears to only care about a single PTL:

 - arch pte_accessible() (x86, arm64) only cares about that one PTE.
 - do_huge_pmd_numa_page() also only cares about a single (huge) page.
 - ksm write_protect_page() also only cares about a single page.

however mm_tlb_flush_nested() is a mystery, it appears to care about
anything inside the range. For now rely on it doing at least _a_ PTL
lock instead of taking  _the_ PTL lock.

Therefore add an explicit smp_mb__after_atomic() to cure things.

Also remove the smp_mb__before_atomic() on the dec side, as its
completely pointless. We must rely on flush_tlb_range() to DTRT.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 include/linux/mm_types.h |   38 ++++++++++++++++++++++----------------
 1 file changed, 22 insertions(+), 16 deletions(-)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -537,13 +537,13 @@ static inline bool mm_tlb_flush_pending(
 {
 	/*
 	 * Must be called with PTL held; such that our PTL acquire will have
-	 * observed the store from set_tlb_flush_pending().
+	 * observed the increment from inc_tlb_flush_pending().
 	 */
-	return atomic_read(&mm->tlb_flush_pending) > 0;
+	return atomic_read(&mm->tlb_flush_pending);
 }
 
 /*
- * Returns true if there are two above TLB batching threads in parallel.
+ * Returns true if there are two or more TLB batching threads in parallel.
  */
 static inline bool mm_tlb_flush_nested(struct mm_struct *mm)
 {
@@ -558,15 +558,12 @@ static inline void init_tlb_flush_pendin
 static inline void inc_tlb_flush_pending(struct mm_struct *mm)
 {
 	atomic_inc(&mm->tlb_flush_pending);
-
 	/*
-	 * The only time this value is relevant is when there are indeed pages
-	 * to flush. And we'll only flush pages after changing them, which
-	 * requires the PTL.
-	 *
 	 * So the ordering here is:
 	 *
 	 *	atomic_inc(&mm->tlb_flush_pending);
+	 *	smp_mb__after_atomic();
+	 *
 	 *	spin_lock(&ptl);
 	 *	...
 	 *	set_pte_at();
@@ -580,21 +577,30 @@ static inline void inc_tlb_flush_pending
 	 *	flush_tlb_range();
 	 *	atomic_dec(&mm->tlb_flush_pending);
 	 *
-	 * So the =true store is constrained by the PTL unlock, and the =false
-	 * store is constrained by the TLB invalidate.
+	 * Where we order the increment against the PTE modification with the
+	 * smp_mb__after_atomic(). It would appear that the spin_unlock(&ptl)
+	 * is sufficient to constrain the inc, because we only care about the
+	 * value if there is indeed a pending PTE modification. However with
+	 * SPLIT_PTE_PTLOCKS and RCpc locks (PPC) the UNLOCK of one lock does
+	 * not order against the LOCK of another lock.
+	 *
+	 * The decrement is ordered by the flush_tlb_range(), such that
+	 * mm_tlb_flush_pending() will not return false unless all flushes have
+	 * completed.
 	 */
+	smp_mb__after_atomic();
 }
 
-/* Clearing is done after a TLB flush, which also provides a barrier. */
 static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 	/*
-	 * Guarantee that the tlb_flush_pending does not not leak into the
-	 * critical section, since we must order the PTE change and changes to
-	 * the pending TLB flush indication. We could have relied on TLB flush
-	 * as a memory barrier, but this behavior is not clearly documented.
+	 * See inc_tlb_flush_pending().
+	 *
+	 * This cannot be smp_mb__before_atomic() because smp_mb() simply does
+	 * not order against TLB invalidate completion, which is what we need.
+	 *
+	 * Therefore we must rely on tlb_flush_*() to guarantee order.
 	 */
-	smp_mb__before_atomic();
 	atomic_dec(&mm->tlb_flush_pending);
 }
 

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 12:44         ` Ingo Molnar
@ 2017-08-11 13:49           ` Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-08-11 13:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Peter Zijlstra, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus

Hi Ingo,

On Fri, 11 Aug 2017 14:44:25 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:  
> > > I've done a minimal conflict resolution merge locally. Peter, could you please 
> > > double check my resolution, in:
> > > 
> > >   040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflicts  
> > 
> > That merge is a bit wonky, but not terminally broken afaict.
> > 
> > It now does two TLB flushes, the below cleans that up.  
> 
> Cool, thanks - I've applied it as a separate commit, to reduce the evilness of the 
> merge commit.
> 
> Will push it all out in time to make Stephen's Monday morning a bit less of a 
> Monday morning.

Thanks you very much.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 12:17       ` Peter Zijlstra
@ 2017-08-11 12:44         ` Ingo Molnar
  2017-08-11 13:49           ` Stephen Rothwell
  0 siblings, 1 reply; 112+ messages in thread
From: Ingo Molnar @ 2017-08-11 12:44 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:
> > I've done a minimal conflict resolution merge locally. Peter, could you please 
> > double check my resolution, in:
> > 
> >   040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflicts
> 
> That merge is a bit wonky, but not terminally broken afaict.
> 
> It now does two TLB flushes, the below cleans that up.

Cool, thanks - I've applied it as a separate commit, to reduce the evilness of the 
merge commit.

Will push it all out in time to make Stephen's Monday morning a bit less of a 
Monday morning.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 11:56     ` Ingo Molnar
@ 2017-08-11 12:17       ` Peter Zijlstra
  2017-08-11 12:44         ` Ingo Molnar
  2017-08-11 14:04       ` Peter Zijlstra
  1 sibling, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-11 12:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus

On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:
> I've done a minimal conflict resolution merge locally. Peter, could you please 
> double check my resolution, in:
> 
>   040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflicts

That merge is a bit wonky, but not terminally broken afaict.

It now does two TLB flushes, the below cleans that up.

---
 mm/huge_memory.c | 22 +++++-----------------
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index ce883459e246..08f6c1993832 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1410,7 +1410,6 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
 	unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
 	int page_nid = -1, this_nid = numa_node_id();
 	int target_nid, last_cpupid = -1;
-	bool need_flush = false;
 	bool page_locked;
 	bool migrated = false;
 	bool was_writable;
@@ -1497,22 +1496,18 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
 	}
 
 	/*
-	 * The page_table_lock above provides a memory barrier
-	 * with change_protection_range.
-	 */
-	if (mm_tlb_flush_pending(vma->vm_mm))
-		flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE);
-
-	/*
 	 * Since we took the NUMA fault, we must have observed the !accessible
 	 * bit. Make sure all other CPUs agree with that, to avoid them
 	 * modifying the page we're about to migrate.
 	 *
 	 * Must be done under PTL such that we'll observe the relevant
-	 * set_tlb_flush_pending().
+	 * inc_tlb_flush_pending().
+	 *
+	 * We are not sure a pending tlb flush here is for a huge page
+	 * mapping or not. Hence use the tlb range variant
 	 */
 	if (mm_tlb_flush_pending(vma->vm_mm))
-		need_flush = true;
+		flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE);
 
 	/*
 	 * Migrate the THP to the requested node, returns with page unlocked
@@ -1520,13 +1515,6 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
 	 */
 	spin_unlock(vmf->ptl);
 
-	/*
-	 * We are not sure a pending tlb flush here is for a huge page
-	 * mapping or not. Hence use the tlb range variant
-	 */
-	if (need_flush)
-		flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE);
-
 	migrated = migrate_misplaced_transhuge_page(vma->vm_mm, vma,
 				vmf->pmd, pmd, vmf->address, page, target_nid);
 	if (migrated) {

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11 11:45   ` Stephen Rothwell
@ 2017-08-11 11:56     ` Ingo Molnar
  2017-08-11 12:17       ` Peter Zijlstra
  2017-08-11 14:04       ` Peter Zijlstra
  0 siblings, 2 replies; 112+ messages in thread
From: Ingo Molnar @ 2017-08-11 11:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Peter Zijlstra, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next Mailing List,
	Linux Kernel Mailing List, Nadav Amit, Linus


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

> Hi Peter,
> 
> On Fri, 11 Aug 2017 11:34:49 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> > > 
> > > Today's linux-next merge of the akpm-current tree got conflicts in:
> > > 
> > >   include/linux/mm_types.h
> > >   mm/huge_memory.c
> > > 
> > > between commit:
> > > 
> > >   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> > > 
> > > from the tip tree and commits:
> > > 
> > >   16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
> > >   a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as possible"")
> > > 
> > > from the akpm-current tree.
> > > 
> > > The latter 2 are now in Linus' tree as well (but were not when I started
> > > the day).
> >
> > Here's two patches that apply on top of tip.
> 
> What I will really need (on Monday) is a merge resolution between
> Linus' tree and the tip tree ...

I've done a minimal conflict resolution merge locally. Peter, could you please 
double check my resolution, in:

  040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflicts

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11  9:34 ` Peter Zijlstra
  2017-08-11 10:48   ` Peter Zijlstra
@ 2017-08-11 11:45   ` Stephen Rothwell
  2017-08-11 11:56     ` Ingo Molnar
  1 sibling, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2017-08-11 11:45 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Nadav Amit,
	Linus

Hi Peter,

On Fri, 11 Aug 2017 11:34:49 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the akpm-current tree got conflicts in:
> > 
> >   include/linux/mm_types.h
> >   mm/huge_memory.c
> > 
> > between commit:
> > 
> >   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> > 
> > from the tip tree and commits:
> > 
> >   16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
> >   a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as possible"")
> > 
> > from the akpm-current tree.
> > 
> > The latter 2 are now in Linus' tree as well (but were not when I started
> > the day).
>
> Here's two patches that apply on top of tip.

What I will really need (on Monday) is a merge resolution between
Linus' tree and the tip tree ...

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11  9:34 ` Peter Zijlstra
@ 2017-08-11 10:48   ` Peter Zijlstra
  2017-08-11 11:45   ` Stephen Rothwell
  1 sibling, 0 replies; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-11 10:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Nadav Amit,
	Linus

On Fri, Aug 11, 2017 at 11:34:49AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the akpm-current tree got conflicts in:
> > 
> >   include/linux/mm_types.h
> >   mm/huge_memory.c
> > 
> > between commit:
> > 
> >   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> > 
> > from the tip tree and commits:
> > 
> >   16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
> >   a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as possible"")
> > 
> > from the akpm-current tree.
> > 
> > The latter 2 are now in Linus' tree as well (but were not when I started
> > the day).
> > 
> > The only way forward I could see was to revert
> > 
> >   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> > 
> > and the three following commits
> > 
> >   ff7a5fb0f1d5 ("overlayfs, locking: Remove smp_mb__before_spinlock() usage")
> >   d89e588ca408 ("locking: Introduce smp_mb__after_spinlock()")
> >   a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")
> > 
> > before merging the akpm-current tree again.
> 
> Here's two patches that apply on top of tip.
> 


And here's one to fix the PPC ordering issue I found while doing those
patches.


---
Subject: mm: Fix barrier for inc_tlb_flush_pending() for PPC
From: Peter Zijlstra <peterz@infradead.org>
Date: Fri Aug 11 12:43:33 CEST 2017

When we have SPLIT_PTE_PTLOCKS and have RCpc locks (PPC) the UNLOCK of
one does not in fact order against the LOCK of another lock. Therefore
the documented scheme does not work.

Add an explicit smp_mb__after_atomic() to cure things.

Also update the comment to reflect the new inc/dec thing.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 include/linux/mm_types.h |   34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -533,7 +533,7 @@ static inline bool mm_tlb_flush_pending(
 {
 	/*
 	 * Must be called with PTL held; such that our PTL acquire will have
-	 * observed the store from set_tlb_flush_pending().
+	 * observed the increment from inc_tlb_flush_pending().
 	 */
 	return atomic_read(&mm->tlb_flush_pending);
 }
@@ -547,13 +547,11 @@ static inline void inc_tlb_flush_pending
 {
 	atomic_inc(&mm->tlb_flush_pending);
 	/*
-	 * The only time this value is relevant is when there are indeed pages
-	 * to flush. And we'll only flush pages after changing them, which
-	 * requires the PTL.
-	 *
 	 * So the ordering here is:
 	 *
-	 *	mm->tlb_flush_pending = true;
+	 *	atomic_inc(&mm->tlb_flush_pending)
+	 *	smp_mb__after_atomic();
+	 *
 	 *	spin_lock(&ptl);
 	 *	...
 	 *	set_pte_at();
@@ -565,17 +563,33 @@ static inline void inc_tlb_flush_pending
 	 *				spin_unlock(&ptl);
 	 *
 	 *	flush_tlb_range();
-	 *	mm->tlb_flush_pending = false;
+	 *	atomic_dec(&mm->tlb_flush_pending);
 	 *
-	 * So the =true store is constrained by the PTL unlock, and the =false
-	 * store is constrained by the TLB invalidate.
+	 * Where we order the increment against the PTE modification with the
+	 * smp_mb__after_atomic(). It would appear that the spin_unlock(&ptl)
+	 * is sufficient to constrain the inc, because we only care about the
+	 * value if there is indeed a pending PTE modification. However with
+	 * SPLIT_PTE_PTLOCKS and RCpc locks (PPC) the UNLOCK of one lock does
+	 * not order against the LOCK of another lock.
+	 *
+	 * The decrement is ordered by the flush_tlb_range(), such that
+	 * mm_tlb_flush_pending() will not return false unless all flushes have
+	 * completed.
 	 */
+	smp_mb__after_atomic();
 }
 
 /* Clearing is done after a TLB flush, which also provides a barrier. */
 static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
-	/* see set_tlb_flush_pending */
+	/*
+	 * See inc_tlb_flush_pending().
+	 *
+	 * This cannot be smp_mb__before_atomic() because smp_mb() simply does
+	 * not order against TLB invalidate completion, which is what we need.
+	 *
+	 * Therefore we must rely on tlb_flush_*() to guarantee order.
+	 */
 	atomic_dec(&mm->tlb_flush_pending);
 }
 #else

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-08-11  7:53 Stephen Rothwell
@ 2017-08-11  9:34 ` Peter Zijlstra
  2017-08-11 10:48   ` Peter Zijlstra
  2017-08-11 11:45   ` Stephen Rothwell
  0 siblings, 2 replies; 112+ messages in thread
From: Peter Zijlstra @ 2017-08-11  9:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, Linux Kernel Mailing List, Nadav Amit,
	Linus

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

On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got conflicts in:
> 
>   include/linux/mm_types.h
>   mm/huge_memory.c
> 
> between commit:
> 
>   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> 
> from the tip tree and commits:
> 
>   16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
>   a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as possible"")
> 
> from the akpm-current tree.
> 
> The latter 2 are now in Linus' tree as well (but were not when I started
> the day).
> 
> The only way forward I could see was to revert
> 
>   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> 
> and the three following commits
> 
>   ff7a5fb0f1d5 ("overlayfs, locking: Remove smp_mb__before_spinlock() usage")
>   d89e588ca408 ("locking: Introduce smp_mb__after_spinlock()")
>   a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")
> 
> before merging the akpm-current tree again.

Here's two patches that apply on top of tip.


[-- Attachment #2: nadav_amit-mm-migrate__prevent_racy_access_to_tlb_flush_pending.patch --]
[-- Type: text/x-diff, Size: 4923 bytes --]

Subject: mm: migrate: prevent racy access to tlb_flush_pending
From: Nadav Amit <nadav.amit@gmail.com>
Date: Tue, 1 Aug 2017 17:08:12 -0700

Setting and clearing mm->tlb_flush_pending can be performed by multiple
threads, since mmap_sem may only be acquired for read in
task_numa_work(). If this happens, tlb_flush_pending might be cleared
while one of the threads still changes PTEs and batches TLB flushes.

This can lead to the same race between migration and
change_protection_range() that led to the introduction of
tlb_flush_pending. The result of this race was data corruption, which
means that this patch also addresses a theoretically possible data
corruption.

An actual data corruption was not observed, yet the race was
was confirmed by adding assertion to check tlb_flush_pending is not set
by two threads, adding artificial latency in change_protection_range()
and using sysctl to reduce kernel.numa_balancing_scan_delay_ms.

Fixes: 20841405940e ("mm: fix TLB flush race between migration, and
change_protection_range")


Cc: <akpm@linux-foundation.org>
Cc: CC:     <nadav.amit@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Nadav Amit <namit@vmware.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20170802000818.4760-2-namit@vmware.com
---
 include/linux/mm_types.h |   29 +++++++++++++++++++++--------
 kernel/fork.c            |    2 +-
 mm/debug.c               |    2 +-
 mm/mprotect.c            |    4 ++--
 4 files changed, 25 insertions(+), 12 deletions(-)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -493,7 +493,7 @@ struct mm_struct {
 	 * can move process memory needs to flush the TLB when moving a
 	 * PROT_NONE or PROT_NUMA mapped page.
 	 */
-	bool tlb_flush_pending;
+	atomic_t tlb_flush_pending;
 #endif
 #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
 	/* See flush_tlb_batched_pending() */
@@ -535,11 +535,17 @@ static inline bool mm_tlb_flush_pending(
 	 * Must be called with PTL held; such that our PTL acquire will have
 	 * observed the store from set_tlb_flush_pending().
 	 */
-	return mm->tlb_flush_pending;
+	return atomic_read(&mm->tlb_flush_pending);
 }
-static inline void set_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void init_tlb_flush_pending(struct mm_struct *mm)
 {
-	mm->tlb_flush_pending = true;
+	atomic_set(&mm->tlb_flush_pending, 0);
+}
+
+static inline void inc_tlb_flush_pending(struct mm_struct *mm)
+{
+	atomic_inc(&mm->tlb_flush_pending);
 	/*
 	 * The only time this value is relevant is when there are indeed pages
 	 * to flush. And we'll only flush pages after changing them, which
@@ -565,21 +571,28 @@ static inline void set_tlb_flush_pending
 	 * store is constrained by the TLB invalidate.
 	 */
 }
+
 /* Clearing is done after a TLB flush, which also provides a barrier. */
-static inline void clear_tlb_flush_pending(struct mm_struct *mm)
+static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 	/* see set_tlb_flush_pending */
-	mm->tlb_flush_pending = false;
+	atomic_dec(&mm->tlb_flush_pending);
 }
 #else
 static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
 {
 	return false;
 }
-static inline void set_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void init_tlb_flush_pending(struct mm_struct *mm)
 {
 }
-static inline void clear_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void inc_tlb_flush_pending(struct mm_struct *mm)
+{
+}
+
+static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 }
 #endif
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -809,7 +809,7 @@ static struct mm_struct *mm_init(struct
 	mm_init_aio(mm);
 	mm_init_owner(mm, p);
 	mmu_notifier_mm_init(mm);
-	clear_tlb_flush_pending(mm);
+	init_tlb_flush_pending(mm);
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
 	mm->pmd_huge_pte = NULL;
 #endif
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -159,7 +159,7 @@ void dump_mm(const struct mm_struct *mm)
 		mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
 #endif
 #if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
-		mm->tlb_flush_pending,
+		atomic_read(&mm->tlb_flush_pending),
 #endif
 		mm->def_flags, &mm->def_flags
 	);
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -244,7 +244,7 @@ static unsigned long change_protection_r
 	BUG_ON(addr >= end);
 	pgd = pgd_offset(mm, addr);
 	flush_cache_range(vma, addr, end);
-	set_tlb_flush_pending(mm);
+	inc_tlb_flush_pending(mm);
 	do {
 		next = pgd_addr_end(addr, end);
 		if (pgd_none_or_clear_bad(pgd))
@@ -256,7 +256,7 @@ static unsigned long change_protection_r
 	/* Only flush the TLB if we actually modified any entries: */
 	if (pages)
 		flush_tlb_range(vma, start, end);
-	clear_tlb_flush_pending(mm);
+	dec_tlb_flush_pending(mm);
 
 	return pages;
 }

[-- Attachment #3: nadav_amit-revert__mm-numa__defer_tlb_flush_for_thp_migration_as_long_as_possible_.patch --]
[-- Type: text/x-diff, Size: 2576 bytes --]

Subject: Revert "mm: numa: defer TLB flush for THP migration as long as possible"
From:   Nadav Amit <namit@vmware.com>
Date: Tue, 1 Aug 2017 17:08:14 -0700

While deferring TLB flushes is a good practice, the reverted patch
caused pending TLB flushes to be checked while the page-table lock is
not taken. As a result, in architectures with weak memory model (PPC),
Linux may miss a memory-barrier, miss the fact TLB flushes are pending,
and cause (in theory) a memory corruption.

Since the alternative of using smp_mb__after_unlock_lock() was
considered a bit open-coded, and the performance impact is expected to
be small, the previous patch is reverted.

This reverts commit b0943d61b8fa420180f92f64ef67662b4f6cc493.

Cc: <akpm@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: CC:     <nadav.amit@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Suggested-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Nadav Amit <namit@vmware.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20170802000818.4760-4-namit@vmware.com
---
 mm/huge_memory.c |   13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1410,7 +1410,6 @@ int do_huge_pmd_numa_page(struct vm_faul
 	unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
 	int page_nid = -1, this_nid = numa_node_id();
 	int target_nid, last_cpupid = -1;
-	bool need_flush = false;
 	bool page_locked;
 	bool migrated = false;
 	bool was_writable;
@@ -1503,9 +1502,12 @@ int do_huge_pmd_numa_page(struct vm_faul
 	 *
 	 * Must be done under PTL such that we'll observe the relevant
 	 * set_tlb_flush_pending().
+	 *
+	 * We are not sure a pending tlb flush here is for a huge page
+	 * mapping or not. Hence use the tlb range variant
 	 */
 	if (mm_tlb_flush_pending(vma->vm_mm))
-		need_flush = true;
+		flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE);
 
 	/*
 	 * Migrate the THP to the requested node, returns with page unlocked
@@ -1513,13 +1515,6 @@ int do_huge_pmd_numa_page(struct vm_faul
 	 */
 	spin_unlock(vmf->ptl);
 
-	/*
-	 * We are not sure a pending tlb flush here is for a huge page
-	 * mapping or not. Hence use the tlb range variant
-	 */
-	if (need_flush)
-		flush_tlb_range(vma, haddr, haddr + HPAGE_PMD_SIZE);
-
 	migrated = migrate_misplaced_transhuge_page(vma->vm_mm, vma,
 				vmf->pmd, pmd, vmf->address, page, target_nid);
 	if (migrated) {

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-08-11  7:53 Stephen Rothwell
  2017-08-11  9:34 ` Peter Zijlstra
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2017-08-11  7:53 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Nadav Amit, Linus

Hi all,

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

  include/linux/mm_types.h
  mm/huge_memory.c

between commit:

  8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")

from the tip tree and commits:

  16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
  a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as possible"")

from the akpm-current tree.

The latter 2 are now in Linus' tree as well (but were not when I started
the day).

The only way forward I could see was to revert

  8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")

and the three following commits

  ff7a5fb0f1d5 ("overlayfs, locking: Remove smp_mb__before_spinlock() usage")
  d89e588ca408 ("locking: Introduce smp_mb__after_spinlock()")
  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

before merging the akpm-current tree again.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-04-12 20:53 ` Vlastimil Babka
@ 2017-04-20  2:17   ` NeilBrown
  0 siblings, 0 replies; 112+ messages in thread
From: NeilBrown @ 2017-04-20  2:17 UTC (permalink / raw)
  To: Vlastimil Babka, Stephen Rothwell, Andrew Morton,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Michal Hocko

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

On Wed, Apr 12 2017, Vlastimil Babka wrote:

> On 12.4.2017 8:46, Stephen Rothwell wrote:
>> Hi Andrew,
>> 
>> Today's linux-next merge of the akpm-current tree got conflicts in:
>> 
>>   drivers/block/nbd.c
>>   drivers/scsi/iscsi_tcp.c
>>   net/core/dev.c
>>   net/core/sock.c
>> 
>> between commit:
>> 
>>   717a94b5fc70 ("sched/core: Remove 'task' parameter and rename tsk_restore_flags() to current_restore_flags()")
>> 
>> from the tip tree and commit:
>> 
>>   61d5ad5b2e8a ("treewide: convert PF_MEMALLOC manipulations to new helpers")
>> 
>> from the akpm-current tree.
>
> Yeah, the first patch from Neil renames a function (as its subject says) and the
> second patch from me converts most of its users to new helpers specific to the
> PF_MEMALLOC flags.
>
>> I fixed it up (the latter is just a superset of the former, so I used
>
> It's not a complete superset though, more on that below.
>
>> that) 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.
>
> Hmm I could redo my patch on top of Neil's patch, but then Andrew would have to
> carry Neil's patch as well just to have a working mmotm? And then make sure to
> send my patch (but not Neil's) only after the tip tree is pulled? Would that
> work for the maintainers involved?
>
>> It looks like there may be more instances that the latter patch should
>> update.
>
> I see two remaining instances of current_restore_flags(). One in __do_softirq()
> is even for PF_MEMALLOC, but there the flag is cleared first and then set back,
> which is opposite of the common case that my helpers provide. The other in nfsd
> is for PF_LESS_THROTTLE which is not common enough to earn own helpers yet. IIRC
> Neil originally wanted to add a new one?

[Sorry - I thought I had sent this last week, but just noticed that I didn't]

In general, I'm not a fan of overly-specific helpers.

As a general rule, tsk_restore_flags() is probably better than
current_restore_flags() as it is more general.
However in this specific case, using any task other than 'current' would
almost certainly be incorrect code as locking is impossible.  So I
prefer the 'current' to be implicit, but the actual flag to be explicit.

If you are going to add helpers for setting/clearing PF flags, I would
much rather that you take

#define current_test_flags(f)   (current->flags & (f))
#define current_set_flags_nested(sp, f)         \
                (*(sp) = current->flags, current->flags |= (f))
#define current_clear_flags_nested(sp, f)       \
                (*(sp) = current->flags, current->flags &= ~(f))
#define current_restore_flags_nested(sp, f)     \
                (current->flags = ((current->flags & ~(f)) | (*(sp) & (f))))

out of fs/xfs/xfs_linux.h and use them globally.

Your
  noreclaim_flag = memalloc_reclaim_save()
becomes
  current_set_flags_nested&noreclaim_flag, PF_MEMALLOC)
which is more typing, but arguably easier to read.

If you then changed all uses of tsk_restore_flags() to use
current_restore_flags_nested(), my patch could be discarded as
irrelevant.

Thanks,
NeilBrown

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2017-04-12  6:46 Stephen Rothwell
@ 2017-04-12 20:53 ` Vlastimil Babka
  2017-04-20  2:17   ` NeilBrown
  0 siblings, 1 reply; 112+ messages in thread
From: Vlastimil Babka @ 2017-04-12 20:53 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, NeilBrown,
	Michal Hocko

On 12.4.2017 8:46, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got conflicts in:
> 
>   drivers/block/nbd.c
>   drivers/scsi/iscsi_tcp.c
>   net/core/dev.c
>   net/core/sock.c
> 
> between commit:
> 
>   717a94b5fc70 ("sched/core: Remove 'task' parameter and rename tsk_restore_flags() to current_restore_flags()")
> 
> from the tip tree and commit:
> 
>   61d5ad5b2e8a ("treewide: convert PF_MEMALLOC manipulations to new helpers")
> 
> from the akpm-current tree.

Yeah, the first patch from Neil renames a function (as its subject says) and the
second patch from me converts most of its users to new helpers specific to the
PF_MEMALLOC flags.

> I fixed it up (the latter is just a superset of the former, so I used

It's not a complete superset though, more on that below.

> that) 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.

Hmm I could redo my patch on top of Neil's patch, but then Andrew would have to
carry Neil's patch as well just to have a working mmotm? And then make sure to
send my patch (but not Neil's) only after the tip tree is pulled? Would that
work for the maintainers involved?

> It looks like there may be more instances that the latter patch should
> update.

I see two remaining instances of current_restore_flags(). One in __do_softirq()
is even for PF_MEMALLOC, but there the flag is cleared first and then set back,
which is opposite of the common case that my helpers provide. The other in nfsd
is for PF_LESS_THROTTLE which is not common enough to earn own helpers yet. IIRC
Neil originally wanted to add a new one?

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-04-12  6:46 Stephen Rothwell
  2017-04-12 20:53 ` Vlastimil Babka
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2017-04-12  6:46 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Vlastimil Babka, NeilBrown

Hi Andrew,

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

  drivers/block/nbd.c
  drivers/scsi/iscsi_tcp.c
  net/core/dev.c
  net/core/sock.c

between commit:

  717a94b5fc70 ("sched/core: Remove 'task' parameter and rename tsk_restore_flags() to current_restore_flags()")

from the tip tree and commit:

  61d5ad5b2e8a ("treewide: convert PF_MEMALLOC manipulations to new helpers")

from the akpm-current tree.

I fixed it up (the latter is just a superset of the former, so I used
that) 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.

It looks like there may be more instances that the latter patch should
update.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-03-24  5:25 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-03-24  5:25 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Dmitry Vyukov

Hi all,

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

  arch/x86/include/asm/atomic.h
  arch/x86/include/asm/atomic64_64.h

between commits:

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

from the tip tree and commit:

  3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")

from the akpm-current tree.

I fixed it up (see below - though more work is probably needed) 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.

The below resolution is not quite right so I added this on top:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 24 Mar 2017 16:14:42 +1100
Subject: [PATCH] fix for bad merge fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/include/asm/atomic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index fc4412567a4a..f717b73182e7 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -217,7 +217,7 @@ static inline void arch_atomic_##op(int i, atomic_t *v)			\
 }
 
 #define ATOMIC_FETCH_OP(op, c_op)					\
-static inline int atomic_fetch_##op(int i, atomic_t *v)			\
+static inline int arch_atomic_fetch_##op(int i, atomic_t *v)		\
 {									\
 	int val = arch_atomic_read(v);					\
 	do {								\
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/atomic.h
index caa5798c92f4,95dd167eb3af..000000000000
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@@ -181,20 -191,14 +191,20 @@@ static __always_inline int arch_atomic_
  	return xadd(&v->counter, -i);
  }
  
- static __always_inline int atomic_cmpxchg(atomic_t *v, int old, int new)
+ static __always_inline int arch_atomic_cmpxchg(atomic_t *v, int old, int new)
  {
- 	return cmpxchg(&v->counter, old, new);
+ 	return arch_cmpxchg(&v->counter, old, new);
  }
  
 +#define atomic_try_cmpxchg atomic_try_cmpxchg
 +static __always_inline bool atomic_try_cmpxchg(atomic_t *v, int *old, int new)
 +{
 +	return try_cmpxchg(&v->counter, old, new);
 +}
 +
- static inline int atomic_xchg(atomic_t *v, int new)
+ static inline int arch_atomic_xchg(atomic_t *v, int new)
  {
- 	return xchg(&v->counter, new);
+ 	return arch_xchg(&v->counter, new);
  }
  
  #define ATOMIC_OP(op)							\
@@@ -207,12 -211,16 +217,12 @@@ static inline void arch_atomic_##op(in
  }
  
  #define ATOMIC_FETCH_OP(op, c_op)					\
 -static inline int arch_atomic_fetch_##op(int i, atomic_t *v)		\
 +static inline int atomic_fetch_##op(int i, atomic_t *v)			\
  {									\
- 	int val = atomic_read(v);					\
 -	int old, val = arch_atomic_read(v);				\
 -	for (;;) {							\
 -		old = arch_atomic_cmpxchg(v, val, val c_op i);		\
 -		if (old == val)						\
 -			break;						\
 -		val = old;						\
 -	}								\
 -	return old;							\
++	int val = arch_atomic_read(v);					\
 +	do {								\
 +	} while (!atomic_try_cmpxchg(v, &val, val c_op i));		\
 +	return val;							\
  }
  
  #define ATOMIC_OPS(op, c_op)						\
@@@ -236,13 -244,18 +246,13 @@@ ATOMIC_OPS(xor, ^
   * Atomically adds @a to @v, so long as @v was not already @u.
   * Returns the old value of @v.
   */
- static __always_inline int __atomic_add_unless(atomic_t *v, int a, int u)
+ static __always_inline int __arch_atomic_add_unless(atomic_t *v, int a, int u)
  {
- 	int c = atomic_read(v);
 -	int c, old;
 -	c = arch_atomic_read(v);
 -	for (;;) {
 -		if (unlikely(c == (u)))
 -			break;
 -		old = arch_atomic_cmpxchg((v), c, c + (a));
 -		if (likely(old == c))
++	int c = arch_atomic_read(v);
 +	do {
 +		if (unlikely(c == u))
  			break;
 -		c = old;
 -	}
 +	} while (!atomic_try_cmpxchg(v, &c, c + a));
  	return c;
  }
  
diff --cc arch/x86/include/asm/atomic64_64.h
index 6189a433c9a9,de9555d35cb0..000000000000
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@@ -168,23 -168,17 +168,23 @@@ static inline long arch_atomic64_fetch_
  	return xadd(&v->counter, -i);
  }
  
- #define atomic64_inc_return(v)  (atomic64_add_return(1, (v)))
- #define atomic64_dec_return(v)  (atomic64_sub_return(1, (v)))
+ #define arch_atomic64_inc_return(v)  (arch_atomic64_add_return(1, (v)))
+ #define arch_atomic64_dec_return(v)  (arch_atomic64_sub_return(1, (v)))
  
- static inline long atomic64_cmpxchg(atomic64_t *v, long old, long new)
+ static inline long arch_atomic64_cmpxchg(atomic64_t *v, long old, long new)
  {
- 	return cmpxchg(&v->counter, old, new);
+ 	return arch_cmpxchg(&v->counter, old, new);
  }
  
 +#define atomic64_try_cmpxchg atomic64_try_cmpxchg
 +static __always_inline bool atomic64_try_cmpxchg(atomic64_t *v, long *old, long new)
 +{
 +	return try_cmpxchg(&v->counter, old, new);
 +}
 +
- static inline long atomic64_xchg(atomic64_t *v, long new)
+ static inline long arch_atomic64_xchg(atomic64_t *v, long new)
  {
- 	return xchg(&v->counter, new);
+ 	return arch_xchg(&v->counter, new);
  }
  
  /**
@@@ -196,29 -190,35 +196,29 @@@
   * Atomically adds @a to @v, so long as it was not @u.
   * Returns the old value of @v.
   */
- static inline bool atomic64_add_unless(atomic64_t *v, long a, long u)
+ static inline bool arch_atomic64_add_unless(atomic64_t *v, long a, long u)
  {
- 	long c = atomic64_read(v);
 -	long c, old;
 -	c = arch_atomic64_read(v);
 -	for (;;) {
 -		if (unlikely(c == (u)))
 -			break;
 -		old = arch_atomic64_cmpxchg((v), c, c + (a));
 -		if (likely(old == c))
 -			break;
 -		c = old;
 -	}
 -	return c != (u);
++	long c = arch_atomic64_read(v);
 +	do {
 +		if (unlikely(c == u))
 +			return false;
 +	} while (!atomic64_try_cmpxchg(v, &c, c + a));
 +	return true;
  }
  
- #define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+ #define arch_atomic64_inc_not_zero(v) arch_atomic64_add_unless((v), 1, 0)
  
  /*
-  * atomic64_dec_if_positive - decrement by 1 if old value positive
+  * arch_atomic64_dec_if_positive - decrement by 1 if old value positive
   * @v: pointer of type atomic_t
   *
   * The function returns the old value of *v minus 1, even if
   * the atomic variable, v, was not decremented.
   */
- static inline long atomic64_dec_if_positive(atomic64_t *v)
+ static inline long arch_atomic64_dec_if_positive(atomic64_t *v)
  {
- 	long dec, c = atomic64_read(v);
 -	long c, old, dec;
 -	c = arch_atomic64_read(v);
 -	for (;;) {
++	long dec, c = arch_atomic64_read(v);
 +	do {
  		dec = c - 1;
  		if (unlikely(dec < 0))
  			break;
@@@ -236,12 -240,16 +236,12 @@@ static inline void arch_atomic64_##op(l
  }
  
  #define ATOMIC64_FETCH_OP(op, c_op)					\
- static inline long atomic64_fetch_##op(long i, atomic64_t *v)		\
+ static inline long arch_atomic64_fetch_##op(long i, atomic64_t *v)	\
  {									\
- 	long val = atomic64_read(v);					\
 -	long old, val = arch_atomic64_read(v);				\
 -	for (;;) {							\
 -		old = arch_atomic64_cmpxchg(v, val, val c_op i);	\
 -		if (old == val)						\
 -			break;						\
 -		val = old;						\
 -	}								\
 -	return old;							\
++	long val = arch_atomic64_read(v);				\
 +	do {								\
 +	} while (!atomic64_try_cmpxchg(v, &val, val c_op i));		\
 +	return val;							\
  }
  
  #define ATOMIC64_OPS(op, c_op)						\

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2017-02-17  4:40 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2017-02-17  4:40 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Frederic Weisbecker, Davidlohr Bueso

Hi all,

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

  arch/cris/include/asm/Kbuild
  arch/m32r/include/asm/Kbuild
  arch/parisc/include/asm/Kbuild
  arch/score/include/asm/Kbuild

between commit:

  b672592f0221 ("sched/cputime: Remove generic asm headers")

from the tip tree and commits:

  ccbd143eeee3 ("cris: use generic current.h")
  103c58f13b54 ("m32r: use generic current.h")
  35a25dde31aa ("score: remove asm/current.h")
  c6b552bc22c7 ("parisc: use generic current.h")

from the akpm-current 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/cris/include/asm/Kbuild
index 9f19e19bff9d,5e320f660c3c..000000000000
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@@ -4,6 -4,8 +4,7 @@@ generic-y += barrier.
  generic-y += bitsperlong.h
  generic-y += clkdev.h
  generic-y += cmpxchg.h
 -generic-y += cputime.h
+ generic-y += current.h
  generic-y += device.h
  generic-y += div64.h
  generic-y += errno.h
diff --cc arch/m32r/include/asm/Kbuild
index 652100b64a71,30ee92ff0244..000000000000
--- a/arch/m32r/include/asm/Kbuild
+++ b/arch/m32r/include/asm/Kbuild
@@@ -1,5 -1,7 +1,6 @@@
  
  generic-y += clkdev.h
 -generic-y += cputime.h
+ generic-y += current.h
  generic-y += exec.h
  generic-y += irq_work.h
  generic-y += kvm_para.h
diff --cc arch/parisc/include/asm/Kbuild
index 4e179d770d69,7ac070267672..000000000000
--- a/arch/parisc/include/asm/Kbuild
+++ b/arch/parisc/include/asm/Kbuild
@@@ -2,6 -2,8 +2,7 @@@
  generic-y += auxvec.h
  generic-y += barrier.h
  generic-y += clkdev.h
 -generic-y += cputime.h
+ generic-y += current.h
  generic-y += device.h
  generic-y += div64.h
  generic-y += emergency-restart.h
diff --cc arch/score/include/asm/Kbuild
index 51970bb6c4fe,620970f837bc..000000000000
--- a/arch/score/include/asm/Kbuild
+++ b/arch/score/include/asm/Kbuild
@@@ -4,6 -4,8 +4,7 @@@ header-y +
  
  generic-y += barrier.h
  generic-y += clkdev.h
 -generic-y += cputime.h
+ generic-y += current.h
  generic-y += irq_work.h
  generic-y += mcs_spinlock.h
  generic-y += mm-arch-hooks.h

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-11-14  6:08 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2016-11-14  6:08 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Sebastian Andrzej Siewior, Vladimir Davydov

Hi Andrew,

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

  mm/memcontrol.c

between commit:

  308167fcb330 ("mm/memcg: Convert to hotplug state machine")

from the tip tree and commit:

  2558c318449d ("mm: memcontrol: use special workqueue for creating per-memcg caches")

from the akpm-current 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 mm/memcontrol.c
index 6c2043509fb5,91dfc7c5ce8f..000000000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5774,8 -5785,18 +5776,19 @@@ static int __init mem_cgroup_init(void
  {
  	int cpu, node;
  
+ #ifndef CONFIG_SLOB
+ 	/*
+ 	 * Kmem cache creation is mostly done with the slab_mutex held,
+ 	 * so use a special workqueue to avoid stalling all worker
+ 	 * threads in case lots of cgroups are created simultaneously.
+ 	 */
+ 	memcg_kmem_cache_create_wq =
+ 		alloc_ordered_workqueue("memcg_kmem_cache_create", 0);
+ 	BUG_ON(!memcg_kmem_cache_create_wq);
+ #endif
+ 
 -	hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
 +	cpuhp_setup_state_nocalls(CPUHP_MM_MEMCQ_DEAD, "mm/memctrl:dead", NULL,
 +				  memcg_hotplug_cpu_dead);
  
  	for_each_possible_cpu(cpu)
  		INIT_WORK(&per_cpu_ptr(&memcg_stock, cpu)->work,

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-07-29  4:14 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2016-07-29  4:14 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski

Hi Andrew,

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

  arch/x86/include/asm/thread_info.h

between commit:

  609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")

from the tip tree and commit:

  58f9594bd42f ("signal: consolidate {TS,TLF}_RESTORE_SIGMASK code")

from the akpm-current 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/include/asm/thread_info.h
index d4b0fd24a63e,b45ffdda3549..000000000000
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@@ -263,35 -219,8 +263,11 @@@ static inline int arch_within_stack_fra
   * have to worry about atomic accesses.
   */
  #define TS_COMPAT		0x0002	/* 32bit syscall active (64BIT)*/
 +#ifdef CONFIG_COMPAT
 +#define TS_I386_REGS_POKED	0x0004	/* regs poked by 32-bit ptracer */
 +#endif
- #define TS_RESTORE_SIGMASK	0x0008	/* restore signal mask in do_signal() */
  
  #ifndef __ASSEMBLY__
- #define HAVE_SET_RESTORE_SIGMASK	1
- static inline void set_restore_sigmask(void)
- {
- 	struct thread_info *ti = current_thread_info();
- 	ti->status |= TS_RESTORE_SIGMASK;
- 	WARN_ON(!test_bit(TIF_SIGPENDING, (unsigned long *)&ti->flags));
- }
- static inline void clear_restore_sigmask(void)
- {
- 	current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
- }
- static inline bool test_restore_sigmask(void)
- {
- 	return current_thread_info()->status & TS_RESTORE_SIGMASK;
- }
- static inline bool test_and_clear_restore_sigmask(void)
- {
- 	struct thread_info *ti = current_thread_info();
- 	if (!(ti->status & TS_RESTORE_SIGMASK))
- 		return false;
- 	ti->status &= ~TS_RESTORE_SIGMASK;
- 	return true;
- }
  
  static inline bool in_ia32_syscall(void)
  {

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2016-06-15  5:23 Stephen Rothwell
@ 2016-06-18 19:39 ` Manfred Spraul
  0 siblings, 0 replies; 112+ messages in thread
From: Manfred Spraul @ 2016-06-18 19:39 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

Hi,

On 06/15/2016 07:23 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>    ipc/sem.c
>
> between commit:
>
>    33ac279677dc ("locking/barriers: Introduce smp_acquire__after_ctrl_dep()")
>
> from the tip tree and commit:
>
>    a1c58ea067cb ("ipc/sem.c: Fix complex_count vs. simple op race")
>
> from the akpm-current tree.
Just in case, I have created a rediff of my patch against -tip.
And the patch with hysteresis would be ready as well.

I will send both patches.

More testers would be welcome, I can only test it on my laptop.

--
     Manfred

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-06-15  5:23 Stephen Rothwell
  2016-06-18 19:39 ` Manfred Spraul
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2016-06-15  5:23 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Manfred Spraul

Hi Andrew,

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

  ipc/sem.c

between commit:

  33ac279677dc ("locking/barriers: Introduce smp_acquire__after_ctrl_dep()")

from the tip tree and commit:

  a1c58ea067cb ("ipc/sem.c: Fix complex_count vs. simple op race")

from the akpm-current 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 ipc/sem.c
index ae72b3cddc8d,11d9e605a619..000000000000
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@@ -260,13 -267,20 +267,10 @@@ static void sem_rcu_free(struct rcu_hea
  }
  
  /*
-  * Wait until all currently ongoing simple ops have completed.
 - * spin_unlock_wait() and !spin_is_locked() are not memory barriers, they
 - * are only control barriers.
 - * The code must pair with spin_unlock(&sem->lock) or
 - * spin_unlock(&sem_perm.lock), thus just the control barrier is insufficient.
 - *
 - * smp_rmb() is sufficient, as writes cannot pass the control barrier.
 - */
 -#define ipc_smp_acquire__after_spin_is_unlocked()	smp_rmb()
 -
 -/*
+  * Enter the mode suitable for non-simple operations:
   * Caller must own sem_perm.lock.
-  * New simple ops cannot start, because simple ops first check
-  * that sem_perm.lock is free.
-  * that a) sem_perm.lock is free and b) complex_count is 0.
   */
- static void sem_wait_array(struct sem_array *sma)
+ static void complexmode_enter(struct sem_array *sma)
  {
  	int i;
  	struct sem *sem;

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2016-04-29  6:12 Stephen Rothwell
@ 2016-04-29  6:26 ` Ingo Molnar
  0 siblings, 0 replies; 112+ messages in thread
From: Ingo Molnar @ 2016-04-29  6:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Shevchenko,
	Matt Fleming, Ard Biesheuvel


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

> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/efi.h
> 
> between commit:
> 
>   2c23b73c2d02 ("Ard Biesheuvel <ard.biesheuvel@linaro.org>")
> 
> from the tip tree and commit:
> 
>   9f2c36a7b097 ("include/linux/efi.h: redefine type, constant, macro from generic code")
> 
> from the akpm-current 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.

Btw., while looking at this, I noticed that akpm-current introduced this namespace 
collision:

include/acpi/acconfig.h:#define UUID_STRING_LENGTH          36  /* Total length of a UUID string */
include/linux/uuid.h:#define    UUID_STRING_LEN         36

I suspect the include/acpi/acconfig.h define should be renamed:

	UUID_STRING_LENGTH -> ACPI_UUID_STRING_LENGTH
	UUID_BUFFER_LENGTH -> ACPI_UUID_BUFFER_LENGTH

... before the collision causes any trouble.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-04-29  6:12 Stephen Rothwell
  2016-04-29  6:26 ` Ingo Molnar
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2016-04-29  6:12 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Shevchenko, Matt Fleming, Ard Biesheuvel

Hi Andrew,

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

  include/linux/efi.h

between commit:

  2c23b73c2d02 ("Ard Biesheuvel <ard.biesheuvel@linaro.org>")

from the tip tree and commit:

  9f2c36a7b097 ("include/linux/efi.h: redefine type, constant, macro from generic code")

from the akpm-current 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 include/linux/efi.h
index aa36fb8bea4b,5b1d5c5b4080..000000000000
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@@ -21,7 -21,7 +21,8 @@@
  #include <linux/pfn.h>
  #include <linux/pstore.h>
  #include <linux/reboot.h>
 +#include <linux/screen_info.h>
+ #include <linux/uuid.h>
  
  #include <asm/page.h>
  

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-03-02  5:40 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2016-03-02  5:40 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Dmitry Vyukov, Josh Poimboeuf

Hi Andrew,

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

  arch/x86/boot/Makefile
  arch/x86/boot/compressed/Makefile
  arch/x86/entry/vdso/Makefile
  arch/x86/kernel/Makefile
  arch/x86/realmode/rm/Makefile
  drivers/firmware/efi/libstub/Makefile

between commit:

  c0dd671686b2 ("objtool: Mark non-standard object files and directories")

from the tip tree and commit:

  9b1ad289b5e5 ("kernel: add kcov code coverage")

from the akpm-current 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/boot/Makefile
index 0bf6749522d9,5f93ca072b21..000000000000
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@@ -9,8 -9,13 +9,14 @@@
  # Changed by many, many contributors over the years.
  #
  
 -KASAN_SANITIZE := n
 +KASAN_SANITIZE			:= n
 +OBJECT_FILES_NON_STANDARD	:= y
+ # Kernel does not boot with kcov instrumentation here.
+ # One of the problems observed was insertion of __sanitizer_cov_trace_pc()
+ # callback into middle of per-cpu data enabling code. Thus the callback observed
+ # inconsistent state and crashed. We are interested mostly in syscall coverage,
+ # so boot code is not interesting anyway.
+ KCOV_INSTRUMENT := n
  
  # If you want to preset the SVGA mode, uncomment the next line and
  # set SVGA_MODE to whatever number you want.
diff --cc arch/x86/boot/compressed/Makefile
index 5e1d26e09407,ad9e9fa5bb11..000000000000
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@@ -16,8 -16,9 +16,10 @@@
  #	(see scripts/Makefile.lib size_append)
  #	compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
  
 -KASAN_SANITIZE := n
 +KASAN_SANITIZE			:= n
 +OBJECT_FILES_NON_STANDARD	:= y
+ # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+ KCOV_INSTRUMENT := n
  
  targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
  	vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4
diff --cc arch/x86/entry/vdso/Makefile
index f9fb859c98b9,5a1993905ace..000000000000
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@@ -3,9 -3,10 +3,11 @@@
  #
  
  KBUILD_CFLAGS += $(DISABLE_LTO)
 -KASAN_SANITIZE := n
 -UBSAN_SANITIZE := n
 +KASAN_SANITIZE			:= n
 +UBSAN_SANITIZE			:= n
 +OBJECT_FILES_NON_STANDARD	:= y
+ # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+ KCOV_INSTRUMENT := n
  
  VDSO64-$(CONFIG_X86_64)		:= y
  VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
diff --cc arch/x86/kernel/Makefile
index d5fb0871aba3,4648960d1c4c..000000000000
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@@ -16,14 -16,14 +16,19 @@@ CFLAGS_REMOVE_ftrace.o = -p
  CFLAGS_REMOVE_early_printk.o = -pg
  endif
  
 -KASAN_SANITIZE_head$(BITS).o := n
 -KASAN_SANITIZE_dumpstack.o := n
 -KASAN_SANITIZE_dumpstack_$(BITS).o := n
 +KASAN_SANITIZE_head$(BITS).o				:= n
 +KASAN_SANITIZE_dumpstack.o				:= n
 +KASAN_SANITIZE_dumpstack_$(BITS).o			:= n
 +
 +OBJECT_FILES_NON_STANDARD_head_$(BITS).o		:= y
 +OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o	:= y
 +OBJECT_FILES_NON_STANDARD_mcount_$(BITS).o		:= y
 +OBJECT_FILES_NON_STANDARD_test_nx.o			:= y
+ # If instrumentation of this dir is enabled, boot hangs during first second.
+ # Probably could be more selective here, but note that files related to irqs,
+ # boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
+ # non-deterministic coverage.
+ KCOV_INSTRUMENT := n
  
  CFLAGS_irq.o := -I$(src)/../include/asm/trace
  
diff --cc arch/x86/realmode/rm/Makefile
index 053abe7b0ef7,35129dcdeb71..000000000000
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@@ -6,8 -6,9 +6,10 @@@
  # for more details.
  #
  #
 -KASAN_SANITIZE := n
 +KASAN_SANITIZE			:= n
 +OBJECT_FILES_NON_STANDARD	:= y
+ # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+ KCOV_INSTRUMENT := n
  
  always := realmode.bin realmode.relocs
  
diff --cc drivers/firmware/efi/libstub/Makefile
index a15841eced4e,37cc9e395edb..000000000000
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@@ -23,7 -23,8 +23,9 @@@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABL
  GCOV_PROFILE			:= n
  KASAN_SANITIZE			:= n
  UBSAN_SANITIZE			:= n
 +OBJECT_FILES_NON_STANDARD	:= y
+ # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+ KCOV_INSTRUMENT			:= n
  
  lib-y				:= efi-stub-helper.o
  

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2016-02-26  5:07 Stephen Rothwell
@ 2016-02-26 21:35 ` Andrew Morton
  0 siblings, 0 replies; 112+ messages in thread
From: Andrew Morton @ 2016-02-26 21:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Dave Hansen, Piotr Kwapulinski

On Fri, 26 Feb 2016 16:07:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/mprotect.c
> 
> between commit:
> 
>   62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys support")
> 
> from the tip tree and commit:
> 
>   aff3915ff831 ("mm/mprotect.c: don't imply PROT_EXEC on non-exec fs")
> 
> from the akpm-current tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/mprotect.c
> index fa37c4cd973a,6ff5dfa65b33..000000000000
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@@ -414,7 -409,11 +411,11 @@@ SYSCALL_DEFINE3(mprotect, unsigned long
>   
>   		/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
>   
> + 		/* Does the application expect PROT_READ to imply PROT_EXEC */
> + 		if (rier && (vma->vm_flags & VM_MAYEXEC))
> + 			prot |= PROT_EXEC;
> + 
>  -		newflags = calc_vm_prot_bits(prot);
>  +		newflags = calc_vm_prot_bits(prot, pkey);
>   		newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
>   
>   		/* newflags >> 4 shift VM_MAY% in place of VM_% */

OK, thanks.

I moved this patch
(mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs.patch) into the
"post-linux-next" section and reworked it to accommodate the -tip
changes.



From: Piotr Kwapulinski <kwapulinski.piotr@gmail.com>
Subject: mm/mprotect.c: don't imply PROT_EXEC on non-exec fs

The mprotect(PROT_READ) fails when called by the READ_IMPLIES_EXEC binary
on a memory mapped file located on non-exec fs.  The mprotect does not
check whether fs is _executable_ or not.  The PROT_EXEC flag is set
automatically even if a memory mapped file is located on non-exec fs.  Fix
it by checking whether a memory mapped file is located on a non-exec fs. 
If so the PROT_EXEC is not implied by the PROT_READ.  The implementation
uses the VM_MAYEXEC flag set properly in mmap.  Now it is consistent with
mmap.

I did the isolated tests (PT_GNU_STACK X/NX, multiple VMAs, X/NX fs).  I
also patched the official 3.19.0-47-generic Ubuntu 14.04 kernel and it
seems to work.

Signed-off-by: Piotr Kwapulinski <kwapulinski.piotr@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/mprotect.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff -puN mm/mprotect.c~mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs mm/mprotect.c
--- a/mm/mprotect.c~mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs
+++ a/mm/mprotect.c
@@ -359,6 +359,9 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 	struct vm_area_struct *vma, *prev;
 	int error = -EINVAL;
 	const int grows = prot & (PROT_GROWSDOWN|PROT_GROWSUP);
+	const bool rier = (current->personality & READ_IMPLIES_EXEC) &&
+				(prot & PROT_READ);
+
 	prot &= ~(PROT_GROWSDOWN|PROT_GROWSUP);
 	if (grows == (PROT_GROWSDOWN|PROT_GROWSUP)) /* can't be both */
 		return -EINVAL;
@@ -375,11 +378,6 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 		return -EINVAL;
 
 	reqprot = prot;
-	/*
-	 * Does the application expect PROT_READ to imply PROT_EXEC:
-	 */
-	if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
-		prot |= PROT_EXEC;
 
 	down_write(&current->mm->mmap_sem);
 
@@ -414,6 +412,10 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 
 		/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
 
+		/* Does the application expect PROT_READ to imply PROT_EXEC */
+		if (rier && (vma->vm_flags & VM_MAYEXEC))
+			prot |= PROT_EXEC;
+
 		newflags = calc_vm_prot_bits(prot, pkey);
 		newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
 
@@ -445,6 +447,7 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 			error = -ENOMEM;
 			goto out;
 		}
+		prot = reqprot;
 	}
 out:
 	up_write(&current->mm->mmap_sem);
_

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-02-26  5:07 Stephen Rothwell
  2016-02-26 21:35 ` Andrew Morton
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2016-02-26  5:07 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Dave Hansen, Piotr Kwapulinski

Hi Andrew,

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

  mm/mprotect.c

between commit:

  62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys support")

from the tip tree and commit:

  aff3915ff831 ("mm/mprotect.c: don't imply PROT_EXEC on non-exec fs")

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc mm/mprotect.c
index fa37c4cd973a,6ff5dfa65b33..000000000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -414,7 -409,11 +411,11 @@@ SYSCALL_DEFINE3(mprotect, unsigned long
  
  		/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
  
+ 		/* Does the application expect PROT_READ to imply PROT_EXEC */
+ 		if (rier && (vma->vm_flags & VM_MAYEXEC))
+ 			prot |= PROT_EXEC;
+ 
 -		newflags = calc_vm_prot_bits(prot);
 +		newflags = calc_vm_prot_bits(prot, pkey);
  		newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
  
  		/* newflags >> 4 shift VM_MAY% in place of VM_% */

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2016-02-19  4:09 Stephen Rothwell
@ 2016-02-19 15:26 ` Ard Biesheuvel
  0 siblings, 0 replies; 112+ messages in thread
From: Ard Biesheuvel @ 2016-02-19 15:26 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Tony Luck

On 19 February 2016 at 05:09, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   arch/x86/mm/extable.c
>
> between commit:
>
>   548acf19234d ("x86/mm: Expand the exception table logic to allow new handling options")
>
> from the tip tree and commit:
>
>   f1cd2c09ff09 ("x86/extable: use generic search and sort routines")
>
> from the akpm-current tree.
>
> I couldn't figure out how to fix this up, so I just dropped the
> akpm-current tree patch.
>

Hi Andrew,

Unfortunately, this is not the only problem currently with my extable
series. The arm64 patch now also conflicts with patches that are
queued in the arm64 tree.

So could you please drop all six of them for now? I will ask Catalin
to take the ones that are essential to the arm64 KASLR implementation
via the arm64 tree, and once that hits mainline, I will rebase and
resubmit the remaining patches.

extable-add-support-for-relative-extables-to-search-and-sort-routines.patch
alpha-extable-use-generic-search-and-sort-routines.patch
s390-extable-use-generic-search-and-sort-routines.patch
x86-extable-use-generic-search-and-sort-routines.patch
ia64-extable-use-generic-search-and-sort-routines.patch
arm64-switch-to-relative-exception-tables.patch

Thanks,
Ard.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2016-02-19  4:09 Stephen Rothwell
  2016-02-19 15:26 ` Ard Biesheuvel
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2016-02-19  4:09 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Tony Luck, Ard Biesheuvel

Hi Andrew,

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

  arch/x86/mm/extable.c

between commit:

  548acf19234d ("x86/mm: Expand the exception table logic to allow new handling options")

from the tip tree and commit:

  f1cd2c09ff09 ("x86/extable: use generic search and sort routines")

from the akpm-current tree.

I couldn't figure out how to fix this up, so I just dropped the
akpm-current tree patch.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-12-07  8:06 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2015-12-07  8:06 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Kirill A. Shutemov, Juergen Gross

Hi Andrew,

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

  arch/x86/mm/pgtable.c

between commit:

  d6ccc3ec9525 ("x86/paravirt: Remove paravirt ops pmd_update[_defer] and pte_update_defer")

from the tip tree and commit:

  275461f0db1f ("x86, thp: remove infrastructure for handling splitting PMDs")

from the akpm-current tree.

I fixed it up (I removed the function (pmdp_splitting_flush) removed by
the latter) and can carry the fix as necessary (no action is required).



-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-10-02  4:21 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2015-10-02  4:21 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Kees Cook

Hi Andrew,

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

  Documentation/filesystems/proc.txt
  fs/proc/array.c
  fs/proc/base.c

between commit:

  b2f73922d119 ("fs/proc, core/debug: Don't expose absolute kernel addresses via wchan")

from the tip tree and commit:

  f01df89b6372 ("fs/proc: don't expose absolute kernel addresses via wchan")
  7adc347341f1 ("fs-proc-dont-expose-absolute-kernel-addresses-via-wchan-fix")

from the akpm-current tree.

I fixed it up (the tip tree version seemed newer, so I used that) and
can carry the fix as necessary (no action is required).

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-09-08 23:21           ` Andrew Morton
@ 2015-09-16  6:58             ` Geert Uytterhoeven
  0 siblings, 0 replies; 112+ messages in thread
From: Geert Uytterhoeven @ 2015-09-16  6:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Stephen Rothwell, Andrea Arcangeli,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, Linux Kernel Mailing List, Andy Lutomirski,
	Eric B Munson, Dr. David Alan Gilbert

Hi Andrew,

On Wed, Sep 9, 2015 at 1:21 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> New syscalls are rather a pain, both from the patch-monkeying POV and
> also because nobody knows what the syscall numbers will be until
> everything lands in mainline.  Oh well, it doesn't happen often and
> it's easy stuff.

One more reason to let the assignment of syscall numbers be handled
(1) by the architecture maintainer, (2) after -rc1, even for x86.

If x86 is no more the canonical source, scripts/checksyscalls.sh needs an
update, though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-09-08 23:03         ` Linus Torvalds
@ 2015-09-08 23:21           ` Andrew Morton
  2015-09-16  6:58             ` Geert Uytterhoeven
  0 siblings, 1 reply; 112+ messages in thread
From: Andrew Morton @ 2015-09-08 23:21 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephen Rothwell, Andrea Arcangeli, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next,
	Linux Kernel Mailing List, Andy Lutomirski, Eric B Munson,
	Dr. David Alan Gilbert

On Tue, 8 Sep 2015 16:03:23 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, Sep 8, 2015 at 3:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have been applying that patch I sent to you to -next for some time.
> > I guess I expected Andrew to pick it up when he rebased his patch
> > series before submitting it to you.  These things sometimes slip
> > through the cracks.
> 
> I suspect Andrew saw that patch, and thought it was a merge fixup like
> you sometimes send out, and didn't realize that it actually applied
> directly to his series.

I've had it all the time, as a post-linux-next fixup - the idea being
that I send it to you after its linux-next preconditions have been
merged up.

However I failed to put that patch inside the stephen-take-these-bits
markers, so it never went from -mm into -next.

New syscalls are rather a pain, both from the patch-monkeying POV and
also because nobody knows what the syscall numbers will be until
everything lands in mainline.  Oh well, it doesn't happen often and
it's easy stuff.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-09-08 22:56       ` Stephen Rothwell
@ 2015-09-08 23:03         ` Linus Torvalds
  2015-09-08 23:21           ` Andrew Morton
  0 siblings, 1 reply; 112+ messages in thread
From: Linus Torvalds @ 2015-09-08 23:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrea Arcangeli, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next,
	Linux Kernel Mailing List, Andy Lutomirski, Eric B Munson,
	Dr. David Alan Gilbert

On Tue, Sep 8, 2015 at 3:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have been applying that patch I sent to you to -next for some time.
> I guess I expected Andrew to pick it up when he rebased his patch
> series before submitting it to you.  These things sometimes slip
> through the cracks.

I suspect Andrew saw that patch, and thought it was a merge fixup like
you sometimes send out, and didn't realize that it actually applied
directly to his series.

              Linus

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-09-08 18:11     ` Linus Torvalds
@ 2015-09-08 22:56       ` Stephen Rothwell
  2015-09-08 23:03         ` Linus Torvalds
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2015-09-08 22:56 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andrea Arcangeli, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next,
	Linux Kernel Mailing List, Andy Lutomirski, Eric B Munson,
	Dr. David Alan Gilbert

Hi Linus,

On Tue, 8 Sep 2015 11:11:25 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, Sep 7, 2015 at 4:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > The below patch was missed when the userfaultfd stuff and the x86 changes
> > were merged.  I have repeated the patch in the clear below.
> 
> When forwarding patches, please add your sign-off. I can see (and
> apply) the original in this thread, so I guess it doesn't matter in
> this particular case, but in general that's what you should be doing
> so that I don't then have to find the other email just to apply the
> patch from the original author.

Ooops, sorry about that.  I really should know better.

> Also, this wasn't actually a real merge error. This was just a bug in
> the whole process. Andrew's patches sent to me had been updated with
> the right number for all the other cases, why hadn't this been folded
> into the series too? Apparently Andrew's series has simply been buggy
> for the last month or more, and that was true even before it was sent
> to me and while it was cooking in -next.. Tssk.

I have been applying that patch I sent to you to -next for some time.
I guess I expected Andrew to pick it up when he rebased his patch
series before submitting it to you.  These things sometimes slip
through the cracks.

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-09-07 23:35   ` Stephen Rothwell
@ 2015-09-08 18:11     ` Linus Torvalds
  2015-09-08 22:56       ` Stephen Rothwell
  0 siblings, 1 reply; 112+ messages in thread
From: Linus Torvalds @ 2015-09-08 18:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrea Arcangeli, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next,
	Linux Kernel Mailing List, Andy Lutomirski, Eric B Munson,
	Dr. David Alan Gilbert

On Mon, Sep 7, 2015 at 4:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The below patch was missed when the userfaultfd stuff and the x86 changes
> were merged.  I have repeated the patch in the clear below.

When forwarding patches, please add your sign-off. I can see (and
apply) the original in this thread, so I guess it doesn't matter in
this particular case, but in general that's what you should be doing
so that I don't then have to find the other email just to apply the
patch from the original author.

Also, this wasn't actually a real merge error. This was just a bug in
the whole process. Andrew's patches sent to me had been updated with
the right number for all the other cases, why hadn't this been folded
into the series too? Apparently Andrew's series has simply been buggy
for the last month or more, and that was true even before it was sent
to me and while it was cooking in -next.. Tssk.

            Linus

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 17:12 ` Andrea Arcangeli
  2015-07-29 17:47   ` Andy Lutomirski
  2015-07-29 23:06   ` Stephen Rothwell
@ 2015-09-07 23:35   ` Stephen Rothwell
  2015-09-08 18:11     ` Linus Torvalds
  2 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2015-09-07 23:35 UTC (permalink / raw)
  To: Linus
  Cc: Andrea Arcangeli, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Andy Lutomirski, Eric B Munson, Dr. David Alan Gilbert

Hi Linus,

On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> >  -359	i386	userfaultfd		sys_userfaultfd
> > ++374	i386	userfaultfd		sys_userfaultfd
> 
> Do I understand correctly the syscall number of userfaultfd for x86
> 32bit has just changed from 359 to 374? Appreciated that you CCed me
> on such a relevant change to be sure I didn't miss it.
> 
> Then the below is needed as well.

The below patch was missed when the userfaultfd stuff and the x86 changes
were merged.  I have repeated the patch in the clear below.

From: Andrea Arcangeli <aarcange@redhat.com>
Date: Wed, 29 Jul 2015 18:53:17 +0200
Subject: [PATCH] userfaultfd: selftest: update userfaultfd x86 32bit syscall number

It changed as result of linux-next merge of other syscalls.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 tools/testing/selftests/vm/userfaultfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c
index 0c0b839..76071b1 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -69,7 +69,7 @@
 #ifdef __x86_64__
 #define __NR_userfaultfd 323
 #elif defined(__i386__)
-#define __NR_userfaultfd 359
+#define __NR_userfaultfd 374
 #elif defined(__powewrpc__)
 #define __NR_userfaultfd 364
 #else

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

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 18:46     ` Thomas Gleixner
@ 2015-07-30 15:38       ` Andrea Arcangeli
  0 siblings, 0 replies; 112+ messages in thread
From: Andrea Arcangeli @ 2015-07-30 15:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Andy Lutomirski, Stephen Rothwell, Andrew Morton, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Andy Lutomirski, Eric B Munson, Dr. David Alan Gilbert

On Wed, Jul 29, 2015 at 08:46:10PM +0200, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Andy Lutomirski wrote:
> > -tip people: want to assign Andrea a pair of syscall numbers?
> 
> Sure, just send a patch ....

Awesome, I just sent the patch to register the syscall against -tip
with the usual placeholder that will return -ENOSYS.

Thanks,
Andrea

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 23:06   ` Stephen Rothwell
@ 2015-07-29 23:07     ` Thomas Gleixner
  0 siblings, 0 replies; 112+ messages in thread
From: Thomas Gleixner @ 2015-07-29 23:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrea Arcangeli, Andrew Morton, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski,
	Eric B Munson, Dr. David Alan Gilbert

On Thu, 30 Jul 2015, Stephen Rothwell wrote:
> Hi Andrea,
> 
> On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
> >
> > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> > >  -359	i386	userfaultfd		sys_userfaultfd
> > > ++374	i386	userfaultfd		sys_userfaultfd
> > 
> > Do I understand correctly the syscall number of userfaultfd for x86
> > 32bit has just changed from 359 to 374? Appreciated that you CCed me
> > on such a relevant change to be sure I didn't miss it.
> > 
> > Then the below is needed as well.
> 
> I have added the below patch to linux-next from today.
> 
> > One related question: is it ok to ship kernels in production right now
> > with the userfaultfd syscall number 374 for x86 32bit ABI (after the
> > above change) and 323 for x86-64 64bit ABI, with these syscalls number
> > registered in linux-next or it may keep changing like it has just
> > happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64
> > 64bit, not all other syscalls in linux-next.
> 
> These numbers are certainly not in any way official, they are just the
> result of my merge conflict fixup.  So, yes, they could change again if
> someone adds another new syscall to any tree but Andrew's.
> 
> > Of course, I know full well that the standard answer is no, and in
> > fact the above is an expected and fine change. In other words what I'm
> > really asking is if I wonder if I could get an agreement here that
> > from now on, the syscall number of userfaultfd for x86 32bit and
> > x86-64 64bit won't change anymore in linux-next and it's already
> > reserved just like if it was already upstream.
> 
> Like Thomas said, send a patch to the x86 maintainers.  I suspect (if
> the rest of the implementation needs to stay in Andrew's tree) that it
> could be a simple as a patch to the syscall tables using ni_syscall and
> a comment.  Thomas?

Yes, that's all it takes to reserve a syscall number.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 17:12 ` Andrea Arcangeli
  2015-07-29 17:47   ` Andy Lutomirski
@ 2015-07-29 23:06   ` Stephen Rothwell
  2015-07-29 23:07     ` Thomas Gleixner
  2015-09-07 23:35   ` Stephen Rothwell
  2 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2015-07-29 23:06 UTC (permalink / raw)
  To: Andrea Arcangeli
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski,
	Eric B Munson, Dr. David Alan Gilbert

Hi Andrea,

On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> >  -359	i386	userfaultfd		sys_userfaultfd
> > ++374	i386	userfaultfd		sys_userfaultfd
> 
> Do I understand correctly the syscall number of userfaultfd for x86
> 32bit has just changed from 359 to 374? Appreciated that you CCed me
> on such a relevant change to be sure I didn't miss it.
> 
> Then the below is needed as well.

I have added the below patch to linux-next from today.

> One related question: is it ok to ship kernels in production right now
> with the userfaultfd syscall number 374 for x86 32bit ABI (after the
> above change) and 323 for x86-64 64bit ABI, with these syscalls number
> registered in linux-next or it may keep changing like it has just
> happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64
> 64bit, not all other syscalls in linux-next.

These numbers are certainly not in any way official, they are just the
result of my merge conflict fixup.  So, yes, they could change again if
someone adds another new syscall to any tree but Andrew's.

> Of course, I know full well that the standard answer is no, and in
> fact the above is an expected and fine change. In other words what I'm
> really asking is if I wonder if I could get an agreement here that
> from now on, the syscall number of userfaultfd for x86 32bit and
> x86-64 64bit won't change anymore in linux-next and it's already
> reserved just like if it was already upstream.

Like Thomas said, send a patch to the x86 maintainers.  I suspect (if
the rest of the implementation needs to stay in Andrew's tree) that it
could be a simple as a patch to the syscall tables using ni_syscall and
a comment.  Thomas?

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 17:47   ` Andy Lutomirski
@ 2015-07-29 18:46     ` Thomas Gleixner
  2015-07-30 15:38       ` Andrea Arcangeli
  0 siblings, 1 reply; 112+ messages in thread
From: Thomas Gleixner @ 2015-07-29 18:46 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Andrea Arcangeli, Stephen Rothwell, Andrew Morton, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Andy Lutomirski, Eric B Munson, Dr. David Alan Gilbert

On Wed, 29 Jul 2015, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 10:12 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> > Hello Stephen,
> >
> > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> >>  -359 i386    userfaultfd             sys_userfaultfd
> >> ++374 i386    userfaultfd             sys_userfaultfd
> >
> > Do I understand correctly the syscall number of userfaultfd for x86
> > 32bit has just changed from 359 to 374? Appreciated that you CCed me
> > on such a relevant change to be sure I didn't miss it.
> >
> > Then the below is needed as well.
> >
> > One related question: is it ok to ship kernels in production right now
> > with the userfaultfd syscall number 374 for x86 32bit ABI (after the
> > above change) and 323 for x86-64 64bit ABI, with these syscalls number
> > registered in linux-next or it may keep changing like it has just
> > happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64
> > 64bit, not all other syscalls in linux-next.
> >
> > Of course, I know full well that the standard answer is no, and in
> > fact the above is an expected and fine change. In other words what I'm
> > really asking is if I wonder if I could get an agreement here that
> > from now on, the syscall number of userfaultfd for x86 32bit and
> > x86-64 64bit won't change anymore in linux-next and it's already
> > reserved just like if it was already upstream.
> >
> > Again: I'd only seek such guarantee for the x86-64 64bit and x86 32bit
> > ABIs (not any other arch, and not any other syscall). If I could get
> > such a guarantee from you within the next week or two, that would
> > avoid me complications and some work, so I thought it was worth
> > asking. If it's not possible never mind.
> 
> My (limited) understanding is that this is up to the arch maintainers.
> I certainly didn't intend to preempt your syscall number, but my patch
> beat your patch to -tip :-p
> 
> -tip people: want to assign Andrea a pair of syscall numbers?

Sure, just send a patch ....


^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-29 17:12 ` Andrea Arcangeli
@ 2015-07-29 17:47   ` Andy Lutomirski
  2015-07-29 18:46     ` Thomas Gleixner
  2015-07-29 23:06   ` Stephen Rothwell
  2015-09-07 23:35   ` Stephen Rothwell
  2 siblings, 1 reply; 112+ messages in thread
From: Andy Lutomirski @ 2015-07-29 17:47 UTC (permalink / raw)
  To: Andrea Arcangeli
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Andy Lutomirski, Eric B Munson, Dr. David Alan Gilbert

On Wed, Jul 29, 2015 at 10:12 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> Hello Stephen,
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
>>  -359 i386    userfaultfd             sys_userfaultfd
>> ++374 i386    userfaultfd             sys_userfaultfd
>
> Do I understand correctly the syscall number of userfaultfd for x86
> 32bit has just changed from 359 to 374? Appreciated that you CCed me
> on such a relevant change to be sure I didn't miss it.
>
> Then the below is needed as well.
>
> One related question: is it ok to ship kernels in production right now
> with the userfaultfd syscall number 374 for x86 32bit ABI (after the
> above change) and 323 for x86-64 64bit ABI, with these syscalls number
> registered in linux-next or it may keep changing like it has just
> happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64
> 64bit, not all other syscalls in linux-next.
>
> Of course, I know full well that the standard answer is no, and in
> fact the above is an expected and fine change. In other words what I'm
> really asking is if I wonder if I could get an agreement here that
> from now on, the syscall number of userfaultfd for x86 32bit and
> x86-64 64bit won't change anymore in linux-next and it's already
> reserved just like if it was already upstream.
>
> Again: I'd only seek such guarantee for the x86-64 64bit and x86 32bit
> ABIs (not any other arch, and not any other syscall). If I could get
> such a guarantee from you within the next week or two, that would
> avoid me complications and some work, so I thought it was worth
> asking. If it's not possible never mind.

My (limited) understanding is that this is up to the arch maintainers.
I certainly didn't intend to preempt your syscall number, but my patch
beat your patch to -tip :-p

-tip people: want to assign Andrea a pair of syscall numbers?

--Andy

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2015-07-28  6:00 Stephen Rothwell
@ 2015-07-29 17:12 ` Andrea Arcangeli
  2015-07-29 17:47   ` Andy Lutomirski
                     ` (2 more replies)
  0 siblings, 3 replies; 112+ messages in thread
From: Andrea Arcangeli @ 2015-07-29 17:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andy Lutomirski,
	Eric B Munson, Dr. David Alan Gilbert

Hello Stephen,

On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
>  -359	i386	userfaultfd		sys_userfaultfd
> ++374	i386	userfaultfd		sys_userfaultfd

Do I understand correctly the syscall number of userfaultfd for x86
32bit has just changed from 359 to 374? Appreciated that you CCed me
on such a relevant change to be sure I didn't miss it.

Then the below is needed as well.

One related question: is it ok to ship kernels in production right now
with the userfaultfd syscall number 374 for x86 32bit ABI (after the
above change) and 323 for x86-64 64bit ABI, with these syscalls number
registered in linux-next or it may keep changing like it has just
happened? I refer only to userfaultfd syscalls of x86 32bit and x86-64
64bit, not all other syscalls in linux-next.

Of course, I know full well that the standard answer is no, and in
fact the above is an expected and fine change. In other words what I'm
really asking is if I wonder if I could get an agreement here that
from now on, the syscall number of userfaultfd for x86 32bit and
x86-64 64bit won't change anymore in linux-next and it's already
reserved just like if it was already upstream.

Again: I'd only seek such guarantee for the x86-64 64bit and x86 32bit
ABIs (not any other arch, and not any other syscall). If I could get
such a guarantee from you within the next week or two, that would
avoid me complications and some work, so I thought it was worth
asking. If it's not possible never mind.

Thanks,
Andrea

===
>From 873093c32b4b1d0b6c3f18ec1e52b56c24f67457 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Wed, 29 Jul 2015 18:53:17 +0200
Subject: [PATCH] userfaultfd: selftest: update userfaultfd x86 32bit syscall
 number

It changed as result of linux-next merge of other syscalls.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 tools/testing/selftests/vm/userfaultfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c
index 0c0b839..76071b1 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -69,7 +69,7 @@
 #ifdef __x86_64__
 #define __NR_userfaultfd 323
 #elif defined(__i386__)
-#define __NR_userfaultfd 359
+#define __NR_userfaultfd 374
 #elif defined(__powewrpc__)
 #define __NR_userfaultfd 364
 #else

^ permalink raw reply related	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-07-28  6:00 Stephen Rothwell
  2015-07-29 17:12 ` Andrea Arcangeli
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2015-07-28  6:00 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski, Eric B Munson,
	Andrea Arcangeli

Hi Andrew,

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

  arch/x86/entry/syscalls/syscall_32.tbl

between commit:

  9dea5dc921b5 ("x86/entry/syscalls: Wire up 32-bit direct socket calls")

from the tip tree and commit:

  0a36ab281187 ("userfaultfd: activate syscall")
  f721d9f04de4 ("mm: mlock: add new mlock, munlock, and munlockall system calls")

from the akpm-current 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/entry/syscalls/syscall_32.tbl
index 25e3cf1cd8fd,d68b13925aa4..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -365,18 -365,7 +365,22 @@@
  356	i386	memfd_create		sys_memfd_create
  357	i386	bpf			sys_bpf
  358	i386	execveat		sys_execveat			stub32_execveat
 -359	i386	userfaultfd		sys_userfaultfd
 -360	i386	mlock2			sys_mlock2
 -361	i386	munlock2		sys_munlock2
 -362	i386	munlockall2		sys_munlockall2
 +359	i386	socket			sys_socket
 +360	i386	socketpair		sys_socketpair
 +361	i386	bind			sys_bind
 +362	i386	connect			sys_connect
 +363	i386	listen			sys_listen
 +364	i386	accept4			sys_accept4
 +365	i386	getsockopt		sys_getsockopt			compat_sys_getsockopt
 +366	i386	setsockopt		sys_setsockopt			compat_sys_setsockopt
 +367	i386	getsockname		sys_getsockname
 +368	i386	getpeername		sys_getpeername
 +369	i386	sendto			sys_sendto
 +370	i386	sendmsg			sys_sendmsg			compat_sys_sendmsg
 +371	i386	recvfrom		sys_recvfrom			compat_sys_recvfrom
 +372	i386	recvmsg			sys_recvmsg			compat_sys_recvmsg
 +373	i386	shutdown		sys_shutdown
++374	i386	userfaultfd		sys_userfaultfd
++375	i386	mlock2			sys_mlock2
++376	i386	munlock2		sys_munlock2
++377	i386	munlockall2		sys_munlockall2

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-06-04 12:07 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2015-06-04 12:07 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Mel Gorman, Josh Triplett

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/Kconfig between commit 6471b825c41e ("x86/kconfig: Reorganize
arch feature Kconfig select's") from the tip tree and commits
be853e68c4b2 ("x86: mm: enable deferred struct page initialisation on
x86-64") and 84ebc29f19b2 ("x86: opt into HAVE_COPY_THREAD_TLS, for
both 32-bit and 64-bit") from the akpm-current 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/Kconfig
index fc1fd8a41540,0dd372f3111e..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -17,113 -23,61 +17,115 @@@ config X86_6
  ### Arch settings
  config X86
  	def_bool y
 -	select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
 -	select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
 +	select ACPI_LEGACY_TABLES_LOOKUP	if ACPI
 +	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
 +	select ANON_INODES
 +	select ARCH_CLOCKSOURCE_DATA
 +	select ARCH_DISCARD_MEMBLOCK
 +	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
  	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 +	select ARCH_HAS_ELF_RANDOMIZE
  	select ARCH_HAS_FAST_MULTIPLIER
  	select ARCH_HAS_GCOV_PROFILE_ALL
 +	select ARCH_HAS_SG_CHAIN
 +	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 +	select ARCH_MIGHT_HAVE_ACPI_PDC		if ACPI
  	select ARCH_MIGHT_HAVE_PC_PARPORT
  	select ARCH_MIGHT_HAVE_PC_SERIO
 -	select HAVE_AOUT if X86_32
 -	select HAVE_UNSTABLE_SCHED_CLOCK
 -	select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
 -	select ARCH_SUPPORTS_INT128 if X86_64
 -	select HAVE_IDE
 -	select HAVE_OPROFILE
 -	select HAVE_PCSPKR_PLATFORM
 -	select HAVE_PERF_EVENTS
 -	select HAVE_IOREMAP_PROT
 -	select HAVE_KPROBES
 -	select HAVE_MEMBLOCK
 -	select HAVE_MEMBLOCK_NODE_MAP
 -	select ARCH_DISCARD_MEMBLOCK
 -	select ARCH_WANT_OPTIONAL_GPIOLIB
 +	select ARCH_SUPPORTS_ATOMIC_RMW
++	select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT	if X86_64
 +	select ARCH_SUPPORTS_INT128		if X86_64
 +	select ARCH_SUPPORTS_NUMA_BALANCING	if X86_64
 +	select ARCH_USE_BUILTIN_BSWAP
 +	select ARCH_USE_CMPXCHG_LOCKREF		if X86_64
 +	select ARCH_USE_QUEUED_RWLOCKS
 +	select ARCH_USE_QUEUED_SPINLOCKS
  	select ARCH_WANT_FRAME_POINTERS
 -	select HAVE_DMA_ATTRS
 -	select HAVE_DMA_CONTIGUOUS
 -	select HAVE_KRETPROBES
 +	select ARCH_WANT_IPC_PARSE_VERSION	if X86_32
 +	select ARCH_WANT_OPTIONAL_GPIOLIB
 +	select BUILDTIME_EXTABLE_SORT
 +	select CLKEVT_I8253
 +	select CLKSRC_I8253			if X86_32
 +	select CLOCKSOURCE_VALIDATE_LAST_CYCLE
 +	select CLOCKSOURCE_WATCHDOG
 +	select CLONE_BACKWARDS			if X86_32
 +	select COMPAT_OLD_SIGACTION		if IA32_EMULATION
 +	select DCACHE_WORD_ACCESS
 +	select EDAC_ATOMIC_SCRUB
 +	select EDAC_SUPPORT
 +	select GENERIC_CLOCKEVENTS
 +	select GENERIC_CLOCKEVENTS_BROADCAST	if X86_64 || (X86_32 && X86_LOCAL_APIC)
 +	select GENERIC_CLOCKEVENTS_MIN_ADJUST
 +	select GENERIC_CMOS_UPDATE
 +	select GENERIC_CPU_AUTOPROBE
  	select GENERIC_EARLY_IOREMAP
 -	select HAVE_OPTPROBES
 -	select HAVE_KPROBES_ON_FTRACE
 -	select HAVE_FTRACE_MCOUNT_RECORD
 -	select HAVE_FENTRY if X86_64
 +	select GENERIC_FIND_FIRST_BIT
 +	select GENERIC_IOMAP
 +	select GENERIC_IRQ_PROBE
 +	select GENERIC_IRQ_SHOW
 +	select GENERIC_PENDING_IRQ		if SMP
 +	select GENERIC_SMP_IDLE_THREAD
 +	select GENERIC_STRNCPY_FROM_USER
 +	select GENERIC_STRNLEN_USER
 +	select GENERIC_TIME_VSYSCALL
 +	select HAVE_ACPI_APEI			if ACPI
 +	select HAVE_ACPI_APEI_NMI		if ACPI
 +	select HAVE_ALIGNED_STRUCT_PAGE		if SLUB
 +	select HAVE_AOUT			if X86_32
 +	select HAVE_ARCH_AUDITSYSCALL
 +	select HAVE_ARCH_HUGE_VMAP		if X86_64 || X86_PAE
 +	select HAVE_ARCH_JUMP_LABEL
 +	select HAVE_ARCH_KASAN			if X86_64 && SPARSEMEM_VMEMMAP
 +	select HAVE_ARCH_KGDB
 +	select HAVE_ARCH_KMEMCHECK
 +	select HAVE_ARCH_SECCOMP_FILTER
 +	select HAVE_ARCH_SOFT_DIRTY		if X86_64
 +	select HAVE_ARCH_TRACEHOOK
 +	select HAVE_ARCH_TRANSPARENT_HUGEPAGE
 +	select HAVE_BPF_JIT			if X86_64
 +	select HAVE_CC_STACKPROTECTOR
 +	select HAVE_CMPXCHG_DOUBLE
 +	select HAVE_CMPXCHG_LOCAL
 +	select HAVE_CONTEXT_TRACKING		if X86_64
++	select HAVE_COPY_THREAD_TLS
  	select HAVE_C_RECORDMCOUNT
 +	select HAVE_DEBUG_KMEMLEAK
 +	select HAVE_DEBUG_STACKOVERFLOW
 +	select HAVE_DMA_API_DEBUG
 +	select HAVE_DMA_ATTRS
 +	select HAVE_DMA_CONTIGUOUS
  	select HAVE_DYNAMIC_FTRACE
  	select HAVE_DYNAMIC_FTRACE_WITH_REGS
 -	select HAVE_FUNCTION_TRACER
 -	select HAVE_FUNCTION_GRAPH_TRACER
 -	select HAVE_FUNCTION_GRAPH_FP_TEST
 -	select HAVE_SYSCALL_TRACEPOINTS
 -	select SYSCTL_EXCEPTION_TRACE
 -	select HAVE_KVM
 -	select HAVE_ARCH_KGDB
 -	select HAVE_ARCH_TRACEHOOK
 -	select HAVE_GENERIC_DMA_COHERENT if X86_32
  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 -	select USER_STACKTRACE_SUPPORT
 -	select HAVE_REGS_AND_STACK_ACCESS_API
 -	select HAVE_DMA_API_DEBUG
 -	select HAVE_KERNEL_GZIP
 +	select HAVE_FENTRY			if X86_64
 +	select HAVE_FTRACE_MCOUNT_RECORD
 +	select HAVE_FUNCTION_GRAPH_FP_TEST
 +	select HAVE_FUNCTION_GRAPH_TRACER
 +	select HAVE_FUNCTION_TRACER
 +	select HAVE_GENERIC_DMA_COHERENT	if X86_32
 +	select HAVE_HW_BREAKPOINT
 +	select HAVE_IDE
 +	select HAVE_IOREMAP_PROT
 +	select HAVE_IRQ_EXIT_ON_IRQ_STACK	if X86_64
 +	select HAVE_IRQ_TIME_ACCOUNTING
  	select HAVE_KERNEL_BZIP2
 +	select HAVE_KERNEL_GZIP
 +	select HAVE_KERNEL_LZ4
  	select HAVE_KERNEL_LZMA
 -	select HAVE_KERNEL_XZ
  	select HAVE_KERNEL_LZO
 -	select HAVE_KERNEL_LZ4
 -	select HAVE_HW_BREAKPOINT
 +	select HAVE_KERNEL_XZ
 +	select HAVE_KPROBES
 +	select HAVE_KPROBES_ON_FTRACE
 +	select HAVE_KRETPROBES
 +	select HAVE_KVM
 +	select HAVE_LIVEPATCH			if X86_64
 +	select HAVE_MEMBLOCK
 +	select HAVE_MEMBLOCK_NODE_MAP
  	select HAVE_MIXED_BREAKPOINTS_REGS
 -	select PERF_EVENTS
 +	select HAVE_OPROFILE
 +	select HAVE_OPTPROBES
 +	select HAVE_PCSPKR_PLATFORM
 +	select HAVE_PERF_EVENTS
  	select HAVE_PERF_EVENTS_NMI
  	select HAVE_PERF_REGS
  	select HAVE_PERF_USER_STACK_DUMP

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-04-08  8:28 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2015-04-08  8:28 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Rasmus Villemoes, Xunlei Pang

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/rtc-mc13xxx.c between commit 0307b0d77a08
("drivers/rtc/mc13xxx: Update driver to address y2038/y2106 issues")
from the tip tree and commit 219451fa4da4 ("drivers/rtc/rtc-mc13xxx.c:
fix obfuscated and wrong format string") from the akpm-current 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 drivers/rtc/rtc-mc13xxx.c
index 32df1d812367,c8e78a560de7..000000000000
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@@ -214,10 -215,12 +214,10 @@@ static int mc13xxx_rtc_set_alarm(struc
  	if (unlikely(ret))
  		goto out;
  
 -	ret = rtc_tm_to_time(&alarm->time, &s1970);
 -	if (unlikely(ret))
 -		goto out;
 +	s1970 = rtc_tm_to_time64(&alarm->time);
  
- 	dev_dbg(dev, "%s: o%2.s %lld\n", __func__, alarm->enabled ? "n" : "ff",
 -	dev_dbg(dev, "%s: %s %lu\n", __func__, alarm->enabled ? "on" : "off",
 -			s1970);
++	dev_dbg(dev, "%s: %s %lld\n", __func__, alarm->enabled ? "on" : "off",
 +			(long long)s1970);
  
  	ret = mc13xxx_rtc_irq_enable_unlocked(dev, alarm->enabled,
  			MC13XXX_IRQ_TODA);

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2015-04-08  8:25 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2015-04-08  8:25 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Matthew Garrett, Xunlei Pang

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/class.c between commit 0fa88cb4b82b ("time, drivers/rtc:
Don't bother with rtc_resume() for the nonstop clocksource") from the
tip tree and commit df9d6ec42558 ("rtc: restore alarm after resume")
from the akpm-current 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 drivers/rtc/class.c
index c29ba7e14304,d46549ce8fd9..000000000000
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@@ -55,7 -55,9 +55,9 @@@ static int rtc_suspend(struct device *d
  	struct timespec64	delta, delta_delta;
  	int err;
  
+ 	rtc->valid_alarm = !rtc_read_alarm(rtc, &rtc->alarm);
+ 
 -	if (has_persistent_clock())
 +	if (timekeeping_rtc_skipsuspend())
  		return 0;
  
  	if (strcmp(dev_name(&rtc->dev), CONFIG_RTC_HCTOSYS_DEVICE) != 0)
@@@ -102,7 -104,28 +104,28 @@@ static int rtc_resume(struct device *de
  	struct timespec64	sleep_time;
  	int err;
  
+ 	/*
+ 	 * Ensure that the platform hasn't overwritten a pending alarm while
+ 	 * suspended
+ 	 */
+ 	if (rtc->valid_alarm) {
+ 		long now, scheduled;
+ 
+ 		rtc_read_time(rtc, &tm);
+ 		rtc_tm_to_time(&rtc->alarm.time, &scheduled);
+ 		rtc_tm_to_time(&tm, &now);
+ 
+ 		/* Clear the alarm registers if it went off during suspend */
+ 		if (scheduled <= now) {
+ 			rtc_time_to_tm(0, &rtc->alarm.time);
+ 			rtc->alarm.enabled = 0;
+ 		}
+ 
+ 		if (rtc->ops && rtc->ops->set_alarm)
+ 			rtc->ops->set_alarm(rtc->dev.parent, &rtc->alarm);
+ 	}
+ 
 -	if (has_persistent_clock())
 +	if (timekeeping_rtc_skipresume())
  		return 0;
  
  	rtc_hctosys_ret = -ENODEV;

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-03-17  9:36 ` Peter Zijlstra
@ 2014-03-19 23:27   ` Andrew Morton
  0 siblings, 0 replies; 112+ messages in thread
From: Andrew Morton @ 2014-03-19 23:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel, Josh Triplett

On Mon, 17 Mar 2014 10:36:02 +0100 Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Mar 17, 2014 at 08:31:24PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict in
> > kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
> > Introduce cancelable MCS lock for adaptive spinning") from the  tree and
> > commit 4dc0fe493027 ("lglock: map to spinlock when !CONFIG_SMP") from the
> > akpm-current tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> I'm a bit sad of not having seen that lglock patch at all.

Here 'tis:

From: Josh Triplett <josh@joshtriplett.org>
Subject: lglock: map to spinlock when !CONFIG_SMP

When the system has only one CPU, lglock is effectively a spinlock; map it
directly to spinlock to eliminate the indirection and duplicate code.

In addition to removing overhead, this drops 1.6k of code with a defconfig
modified to have !CONFIG_SMP, and 1.1k with a minimal config.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Howells <dhowells@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/lglock.h  |   16 ++++++++++++++++
 kernel/locking/Makefile |    3 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff -puN include/linux/lglock.h~lglock-map-to-spinlock-when-config_smp include/linux/lglock.h
--- a/include/linux/lglock.h~lglock-map-to-spinlock-when-config_smp
+++ a/include/linux/lglock.h
@@ -25,6 +25,8 @@
 #include <linux/cpu.h>
 #include <linux/notifier.h>
 
+#ifdef CONFIG_SMP
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 #define LOCKDEP_INIT_MAP lockdep_init_map
 #else
@@ -57,4 +59,18 @@ void lg_local_unlock_cpu(struct lglock *
 void lg_global_lock(struct lglock *lg);
 void lg_global_unlock(struct lglock *lg);
 
+#else
+/* When !CONFIG_SMP, map lglock to spinlock */
+#define lglock spinlock
+#define DEFINE_LGLOCK(name) DEFINE_SPINLOCK(name)
+#define DEFINE_STATIC_LGLOCK(name) static DEFINE_SPINLOCK(name)
+#define lg_lock_init(lg, name) spin_lock_init(lg)
+#define lg_local_lock spin_lock
+#define lg_local_unlock spin_unlock
+#define lg_local_lock_cpu(lg, cpu) spin_lock(lg)
+#define lg_local_unlock_cpu(lg, cpu) spin_unlock(lg)
+#define lg_global_lock spin_lock
+#define lg_global_unlock spin_unlock
+#endif
+
 #endif
diff -puN kernel/locking/Makefile~lglock-map-to-spinlock-when-config_smp kernel/locking/Makefile
--- a/kernel/locking/Makefile~lglock-map-to-spinlock-when-config_smp
+++ a/kernel/locking/Makefile
@@ -1,5 +1,5 @@
 
-obj-y += mutex.o semaphore.o rwsem.o lglock.o mcs_spinlock.o
+obj-y += mutex.o semaphore.o rwsem.o mcs_spinlock.o
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_lockdep.o = -pg
@@ -14,6 +14,7 @@ ifeq ($(CONFIG_PROC_FS),y)
 obj-$(CONFIG_LOCKDEP) += lockdep_proc.o
 endif
 obj-$(CONFIG_SMP) += spinlock.o
+obj-$(CONFIG_SMP) += lglock.o
 obj-$(CONFIG_PROVE_LOCKING) += spinlock.o
 obj-$(CONFIG_RT_MUTEXES) += rtmutex.o
 obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o
_


^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-03-17  9:31 Stephen Rothwell
@ 2014-03-17  9:36 ` Peter Zijlstra
  2014-03-19 23:27   ` Andrew Morton
  0 siblings, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2014-03-17  9:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel, Josh Triplett

On Mon, Mar 17, 2014 at 08:31:24PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
> Introduce cancelable MCS lock for adaptive spinning") from the  tree and
> commit 4dc0fe493027 ("lglock: map to spinlock when !CONFIG_SMP") from the
> akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I'm a bit sad of not having seen that lglock patch at all.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2014-03-17  9:31 Stephen Rothwell
  2014-03-17  9:36 ` Peter Zijlstra
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2014-03-17  9:31 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Josh Triplett

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
Introduce cancelable MCS lock for adaptive spinning") from the  tree and
commit 4dc0fe493027 ("lglock: map to spinlock when !CONFIG_SMP") from the
akpm-current 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/locking/Makefile
index 306a76b51e0f,727fefd00c71..000000000000
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@@ -1,5 -1,5 +1,5 @@@
  
- obj-y += mutex.o semaphore.o rwsem.o lglock.o mcs_spinlock.o
 -obj-y += mutex.o semaphore.o rwsem.o
++obj-y += mutex.o semaphore.o rwsem.o mcs_spinlock.o
  
  ifdef CONFIG_FUNCTION_TRACER
  CFLAGS_REMOVE_lockdep.o = -pg

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 13:17   ` Geert Uytterhoeven
  2014-01-14 13:33     ` Peter Zijlstra
@ 2014-01-14 16:19     ` H. Peter Anvin
  1 sibling, 0 replies; 112+ messages in thread
From: H. Peter Anvin @ 2014-01-14 16:19 UTC (permalink / raw)
  To: Geert Uytterhoeven, Peter Zijlstra
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	Linux-Next, linux-kernel, Davidlohr Bueso

On 01/14/2014 05:17 AM, Geert Uytterhoeven wrote:
>>
>> This seems terribly broken, the *futex_value*() ops should not need
>> that; they are supposed to access userspace without any of that.
> 
> Why don't they need set_fs(USER_DS)?
> 
> Gr{oetje,eeting}s,
> 
>                         Geert

Because USER_DS is the normal operating state?  It would appear m68k is
the only(?) arch that calls initcalls with get_fs() == KERNEL_DS...

	-hpa



^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 15:41       ` Peter Zijlstra
@ 2014-01-14 15:48         ` H. Peter Anvin
  0 siblings, 0 replies; 112+ messages in thread
From: H. Peter Anvin @ 2014-01-14 15:48 UTC (permalink / raw)
  To: Peter Zijlstra, Geert Uytterhoeven
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	Linux-Next, linux-kernel, Davidlohr Bueso

On 01/14/2014 07:41 AM, Peter Zijlstra wrote:
>>>
>>> I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that
>>> futex_init() is called.  This would seem a bit of a peculiarity to m68k,
>>> and as such it would seem like it would be better for it to belong in
>>> the m68k-specific code, but since futex_init() is init code and only
>>> called once anyway it shouldn't cause any harm...
>>
>> Yes it does. So when getting the exception on 68030, we notice it's a kernel
>> space access error, not a user space access error, and crash.
> 
> Is there a good reason m68k works like this? That is, shouldn't we fix
> the arch code instead of littering the generic code with weirdness like
> this?
> 

Given that futex_init is called from initcall, this seems *really* weird
on the part of m68k.  I agree this should be fixed where the problem sits.

	-hpa


^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 15:20     ` Geert Uytterhoeven
@ 2014-01-14 15:41       ` Peter Zijlstra
  2014-01-14 15:48         ` H. Peter Anvin
  0 siblings, 1 reply; 112+ messages in thread
From: Peter Zijlstra @ 2014-01-14 15:41 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: H. Peter Anvin, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, Linux-Next, linux-kernel, Davidlohr Bueso

On Tue, Jan 14, 2014 at 04:20:36PM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 14, 2014 at 4:15 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
> >> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> >>> Hi Andrew,
> >>>
> >>> Today's linux-next merge of the akpm-current tree got a conflict in
> >>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> >>> size for better performance") from the tip tree and commit 61beee6c76e5
> >>> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
> >>>
> >>> @@@ -2869,10 -2748,13 +2871,13 @@@
> >>>       * implementation, the non-functional ones will return
> >>>       * -ENOSYS.
> >>>       */
> >>> +    fs = get_fs();
> >>> +    set_fs(USER_DS);
> >>>      if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
> >>>              futex_cmpxchg_enabled = 1;
> >>> +    set_fs(fs);
> >>>
> >>
> >> This seems terribly broken, the *futex_value*() ops should not need
> >> that; they are supposed to access userspace without any of that.
> >
> > I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that
> > futex_init() is called.  This would seem a bit of a peculiarity to m68k,
> > and as such it would seem like it would be better for it to belong in
> > the m68k-specific code, but since futex_init() is init code and only
> > called once anyway it shouldn't cause any harm...
> 
> Yes it does. So when getting the exception on 68030, we notice it's a kernel
> space access error, not a user space access error, and crash.

Is there a good reason m68k works like this? That is, shouldn't we fix
the arch code instead of littering the generic code with weirdness like
this?

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 15:15   ` H. Peter Anvin
@ 2014-01-14 15:20     ` Geert Uytterhoeven
  2014-01-14 15:41       ` Peter Zijlstra
  0 siblings, 1 reply; 112+ messages in thread
From: Geert Uytterhoeven @ 2014-01-14 15:20 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Peter Zijlstra, Stephen Rothwell, Andrew Morton, Thomas Gleixner,
	Ingo Molnar, Linux-Next, linux-kernel, Davidlohr Bueso

On Tue, Jan 14, 2014 at 4:15 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
>> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>>> Hi Andrew,
>>>
>>> Today's linux-next merge of the akpm-current tree got a conflict in
>>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
>>> size for better performance") from the tip tree and commit 61beee6c76e5
>>> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
>>>
>>> @@@ -2869,10 -2748,13 +2871,13 @@@
>>>       * implementation, the non-functional ones will return
>>>       * -ENOSYS.
>>>       */
>>> +    fs = get_fs();
>>> +    set_fs(USER_DS);
>>>      if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
>>>              futex_cmpxchg_enabled = 1;
>>> +    set_fs(fs);
>>>
>>
>> This seems terribly broken, the *futex_value*() ops should not need
>> that; they are supposed to access userspace without any of that.
>
> I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that
> futex_init() is called.  This would seem a bit of a peculiarity to m68k,
> and as such it would seem like it would be better for it to belong in
> the m68k-specific code, but since futex_init() is init code and only
> called once anyway it shouldn't cause any harm...

Yes it does. So when getting the exception on 68030, we notice it's a kernel
space access error, not a user space access error, and crash.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 12:51 ` Peter Zijlstra
  2014-01-14 13:17   ` Geert Uytterhoeven
@ 2014-01-14 15:15   ` H. Peter Anvin
  2014-01-14 15:20     ` Geert Uytterhoeven
  1 sibling, 1 reply; 112+ messages in thread
From: H. Peter Anvin @ 2014-01-14 15:15 UTC (permalink / raw)
  To: Peter Zijlstra, Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, linux-next,
	linux-kernel, Geert Uytterhoeven, Davidlohr Bueso

On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in
>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
>> size for better performance") from the tip tree and commit 61beee6c76e5
>> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
>>
>> @@@ -2869,10 -2748,13 +2871,13 @@@
>>   	 * implementation, the non-functional ones will return
>>   	 * -ENOSYS.
>>   	 */
>> + 	fs = get_fs();
>> + 	set_fs(USER_DS);
>>   	if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
>>   		futex_cmpxchg_enabled = 1;
>> + 	set_fs(fs);
>>   
> 
> This seems terribly broken, the *futex_value*() ops should not need
> that; they are supposed to access userspace without any of that.
> 

I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that
futex_init() is called.  This would seem a bit of a peculiarity to m68k,
and as such it would seem like it would be better for it to belong in
the m68k-specific code, but since futex_init() is init code and only
called once anyway it shouldn't cause any harm...

	-hpa


^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 13:17   ` Geert Uytterhoeven
@ 2014-01-14 13:33     ` Peter Zijlstra
  2014-01-14 16:19     ` H. Peter Anvin
  1 sibling, 0 replies; 112+ messages in thread
From: Peter Zijlstra @ 2014-01-14 13:33 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next, linux-kernel, Davidlohr Bueso

On Tue, Jan 14, 2014 at 02:17:55PM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> >> Today's linux-next merge of the akpm-current tree got a conflict in
> >> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> >> size for better performance") from the tip tree and commit 61beee6c76e5
> >> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
> >>
> >> @@@ -2869,10 -2748,13 +2871,13 @@@
> >>        * implementation, the non-functional ones will return
> >>        * -ENOSYS.
> >>        */
> >> +     fs = get_fs();
> >> +     set_fs(USER_DS);
> >>       if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
> >>               futex_cmpxchg_enabled = 1;
> >> +     set_fs(fs);
> >>
> >
> > This seems terribly broken, the *futex_value*() ops should not need
> > that; they are supposed to access userspace without any of that.
> 
> Why don't they need set_fs(USER_DS)?

Why would they need it? These functions explicitly take a __user pointer
and are expected to do whatever is needed to perform the operation. None
of the other futex bits use USER_DS either.


Furthermore, from the Changelog of:
e4f2dfbb5e92be4e46c0625f4f8eb101110f756f

"   This patch adds that support, but only for uniprocessor machines,
    which is adequate for M68K.  For UP it's enough to disable preemption
    to ensure mutual exclusion (futexes don't need to care about other
    hardware agents), and the mandatory pagefault_disable() does just that.  "

It is wrong to rely on the fact that pagefault_disable() disables
preemption. This is fact not true on -rt.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14 12:51 ` Peter Zijlstra
@ 2014-01-14 13:17   ` Geert Uytterhoeven
  2014-01-14 13:33     ` Peter Zijlstra
  2014-01-14 16:19     ` H. Peter Anvin
  2014-01-14 15:15   ` H. Peter Anvin
  1 sibling, 2 replies; 112+ messages in thread
From: Geert Uytterhoeven @ 2014-01-14 13:17 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Linux-Next, linux-kernel, Davidlohr Bueso

On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in
>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
>> size for better performance") from the tip tree and commit 61beee6c76e5
>> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
>>
>> @@@ -2869,10 -2748,13 +2871,13 @@@
>>        * implementation, the non-functional ones will return
>>        * -ENOSYS.
>>        */
>> +     fs = get_fs();
>> +     set_fs(USER_DS);
>>       if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
>>               futex_cmpxchg_enabled = 1;
>> +     set_fs(fs);
>>
>
> This seems terribly broken, the *futex_value*() ops should not need
> that; they are supposed to access userspace without any of that.

Why don't they need set_fs(USER_DS)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14  4:53 Stephen Rothwell
  2014-01-14  5:04 ` Davidlohr Bueso
@ 2014-01-14 12:51 ` Peter Zijlstra
  2014-01-14 13:17   ` Geert Uytterhoeven
  2014-01-14 15:15   ` H. Peter Anvin
  1 sibling, 2 replies; 112+ messages in thread
From: Peter Zijlstra @ 2014-01-14 12:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	linux-next, linux-kernel, Geert Uytterhoeven, Davidlohr Bueso

On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> size for better performance") from the tip tree and commit 61beee6c76e5
> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
> 
> @@@ -2869,10 -2748,13 +2871,13 @@@
>   	 * implementation, the non-functional ones will return
>   	 * -ENOSYS.
>   	 */
> + 	fs = get_fs();
> + 	set_fs(USER_DS);
>   	if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
>   		futex_cmpxchg_enabled = 1;
> + 	set_fs(fs);
>   

This seems terribly broken, the *futex_value*() ops should not need
that; they are supposed to access userspace without any of that.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-14  4:53 Stephen Rothwell
@ 2014-01-14  5:04 ` Davidlohr Bueso
  2014-01-14 12:51 ` Peter Zijlstra
  1 sibling, 0 replies; 112+ messages in thread
From: Davidlohr Bueso @ 2014-01-14  5:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Geert Uytterhoeven

On Tue, 2014-01-14 at 15:53 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> size for better performance") from the tip tree and commit 61beee6c76e5
> ("futex: switch to USER_DS for futex test") from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks Stephen. At least for my bits the fix seems ok. In the future,
though, changes to this evil file should be routed only through one
tree.

Thanks,
Davidlohr


^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2014-01-14  4:53 Stephen Rothwell
  2014-01-14  5:04 ` Davidlohr Bueso
  2014-01-14 12:51 ` Peter Zijlstra
  0 siblings, 2 replies; 112+ messages in thread
From: Stephen Rothwell @ 2014-01-14  4:53 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Geert Uytterhoeven, Davidlohr Bueso

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
size for better performance") from the tip tree and commit 61beee6c76e5
("futex: switch to USER_DS for futex test") from the akpm-current 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/futex.c
index 3666aa0017ed,66d23727c6ab..000000000000
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@@ -63,7 -63,7 +63,8 @@@
  #include <linux/sched/rt.h>
  #include <linux/hugetlb.h>
  #include <linux/freezer.h>
 +#include <linux/bootmem.h>
+ #include <linux/uaccess.h>
  
  #include <asm/futex.h>
  
@@@ -2845,19 -2734,9 +2846,20 @@@ SYSCALL_DEFINE6(futex, u32 __user *, ua
  
  static int __init futex_init(void)
  {
+ 	mm_segment_t fs;
  	u32 curval;
 -	int i;
 +	unsigned long i;
 +
 +#if CONFIG_BASE_SMALL
 +	futex_hashsize = 16;
 +#else
 +	futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
 +#endif
 +
 +	futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
 +					       futex_hashsize, 0,
 +					       futex_hashsize < 256 ? HASH_SMALL : 0,
 +					       NULL, NULL, futex_hashsize, futex_hashsize);
  
  	/*
  	 * This will fail and we want it. Some arch implementations do
@@@ -2869,10 -2748,13 +2871,13 @@@
  	 * implementation, the non-functional ones will return
  	 * -ENOSYS.
  	 */
+ 	fs = get_fs();
+ 	set_fs(USER_DS);
  	if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
  		futex_cmpxchg_enabled = 1;
+ 	set_fs(fs);
  
 -	for (i = 0; i < ARRAY_SIZE(futex_queues); i++) {
 +	for (i = 0; i < futex_hashsize; i++) {
  		plist_head_init(&futex_queues[i].chain);
  		spin_lock_init(&futex_queues[i].lock);
  	}

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
  2014-01-07  6:00 Stephen Rothwell
@ 2014-01-07  6:34 ` Tang Chen
  0 siblings, 0 replies; 112+ messages in thread
From: Tang Chen @ 2014-01-07  6:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Lans Zhang,
	Yasuaki Ishimatsu, Lai Jiangshan, Jiang Liu, Zhang Yanfei

On 01/07/2014 02:00 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
> kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
> pg_data_t's memory from other node") from the akpm-current tree.
>
> These appear to be two very similar solutions, I fixed it up (see below -
> I (arbitrarily) chose to keep the actual allocation from the tip tree, but
> the messages from the akpm-current tree) and can carry the fix as
> necessary (no action is required).
>

memblock_alloc_nid() and __memblock_alloc_base() will call
memblock_alloc_base_nid() in the end. So I think it is OK to me.

I will do some tests when they are merged.

Thanks.

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2014-01-07  6:00 Stephen Rothwell
  2014-01-07  6:34 ` Tang Chen
  0 siblings, 1 reply; 112+ messages in thread
From: Stephen Rothwell @ 2014-01-07  6:00 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Lans Zhang, Yasuaki Ishimatsu,
	Lai Jiangshan, Tang Chen, Jiang Liu, Zhang Yanfei

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
pg_data_t's memory from other node") from the akpm-current tree.

These appear to be two very similar solutions, I fixed it up (see below -
I (arbitrarily) chose to keep the actual allocation from the tip tree, but
the messages from the akpm-current tree) 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 c85da7bb6b60,f26b16f0d3e0..000000000000
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -211,11 -211,12 +211,12 @@@ static void __init setup_node_data(int 
  	 */
  	nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
  	if (!nd_pa) {
+ 		pr_warn("Cannot find %zu bytes in node %d, so try other nodes",
+ 			nd_size, nid);
 -		nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES,
 -					   MAX_NUMNODES);
 +		nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
 +					      MEMBLOCK_ALLOC_ACCESSIBLE);
  		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;
  		}
  	}

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

* linux-next: manual merge of the akpm-current tree with the tip tree
@ 2013-10-30  6:40 Stephen Rothwell
  0 siblings, 0 replies; 112+ messages in thread
From: Stephen Rothwell @ 2013-10-30  6:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Yinghai Lu, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
	Zhang Yanfei

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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/init.c between commit 6979287a7df6 ("x86/mm: Add 'step_size'
comments to init_mem_mapping()") from the tip tree and commits
6452c268c6d6 ("x86/mm: factor out of top-down direct mapping setup") and
f790250c098a ("x86/mem-hotplug: support initialize page tables in
bottom-up") from the akpm-current 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/init.c
index ce32017c5e38,b6892a71cbfc..000000000000
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@@ -399,28 -399,23 +399,39 @@@ static unsigned long __init init_range_
  	return mapped_ram_size;
  }
  
 -/* (PUD_SHIFT-PMD_SHIFT)/2 */
 -#define STEP_SIZE_SHIFT 5
 +static unsigned long __init get_new_step_size(unsigned long step_size)
 +{
 +	/*
 +	 * Explain why we shift by 5 and why we don't have to worry about
 +	 * 'step_size << 5' overflowing:
 +	 *
 +	 * initial mapped size is PMD_SIZE (2M).
 +	 * We can not set step_size to be PUD_SIZE (1G) yet.
 +	 * In worse case, when we cross the 1G boundary, and
 +	 * PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M + 8k)
 +	 * to map 1G range with PTE. Use 5 as shift for now.
 +	 *
 +	 * Don't need to worry about overflow, on 32bit, when step_size
 +	 * is 0, round_down() returns 0 for start, and that turns it
 +	 * into 0x100000000ULL.
 +	 */
 +	return step_size << 5;
 +}
  
- void __init init_mem_mapping(void)
+ /**
+  * memory_map_top_down - Map [map_start, map_end) top down
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in top-down. That said, the page tables
+  * will be allocated at the end of the memory, and we map the
+  * memory in top-down.
+  */
+ static void __init memory_map_top_down(unsigned long map_start,
+ 				       unsigned long map_end)
  {
- 	unsigned long end, real_end, start, last_start;
+ 	unsigned long real_end, start, last_start;
  	unsigned long step_size;
  	unsigned long addr;
  	unsigned long mapped_ram_size = 0;
@@@ -470,8 -454,89 +470,89 @@@
  		mapped_ram_size += new_mapped_ram_size;
  	}
  
- 	if (real_end < end)
- 		init_range_memory_mapping(real_end, end);
+ 	if (real_end < map_end)
+ 		init_range_memory_mapping(real_end, map_end);
+ }
+ 
+ /**
+  * memory_map_bottom_up - Map [map_start, map_end) bottom up
+  * @map_start: start address of the target memory range
+  * @map_end: end address of the target memory range
+  *
+  * This function will setup direct mapping for memory range
+  * [map_start, map_end) in bottom-up. Since we have limited the
+  * bottom-up allocation above the kernel, the page tables will
+  * be allocated just above the kernel and we map the memory
+  * in [map_start, map_end) in bottom-up.
+  */
+ static void __init memory_map_bottom_up(unsigned long map_start,
+ 					unsigned long map_end)
+ {
+ 	unsigned long next, new_mapped_ram_size, start;
+ 	unsigned long mapped_ram_size = 0;
+ 	/* step_size need to be small so pgt_buf from BRK could cover it */
+ 	unsigned long step_size = PMD_SIZE;
+ 
+ 	start = map_start;
+ 	min_pfn_mapped = start >> PAGE_SHIFT;
+ 
+ 	/*
+ 	 * We start from the bottom (@map_start) and go to the top (@map_end).
+ 	 * The memblock_find_in_range() gets us a block of RAM from the
+ 	 * end of RAM in [min_pfn_mapped, max_pfn_mapped) used as new pages
+ 	 * for page table.
+ 	 */
+ 	while (start < map_end) {
+ 		if (map_end - start > step_size) {
+ 			next = round_up(start + 1, step_size);
+ 			if (next > map_end)
+ 				next = map_end;
+ 		} else
+ 			next = map_end;
+ 
+ 		new_mapped_ram_size = init_range_memory_mapping(start, next);
+ 		start = next;
+ 
+ 		if (new_mapped_ram_size > mapped_ram_size)
 -			step_size <<= STEP_SIZE_SHIFT;
++			step_size = get_new_step_size(step_size);
+ 		mapped_ram_size += new_mapped_ram_size;
+ 	}
+ }
+ 
+ void __init init_mem_mapping(void)
+ {
+ 	unsigned long end;
+ 
+ 	probe_page_size_mask();
+ 
+ #ifdef CONFIG_X86_64
+ 	end = max_pfn << PAGE_SHIFT;
+ #else
+ 	end = max_low_pfn << PAGE_SHIFT;
+ #endif
+ 
+ 	/* the ISA range is always mapped regardless of memory holes */
+ 	init_memory_mapping(0, ISA_END_ADDRESS);
+ 
+ 	/*
+ 	 * If the allocation is in bottom-up direction, we setup direct mapping
+ 	 * in bottom-up, otherwise we setup direct mapping in top-down.
+ 	 */
+ 	if (memblock_bottom_up()) {
+ 		unsigned long kernel_end = __pa_symbol(_end);
+ 
+ 		/*
+ 		 * we need two separate calls here. This is because we want to
+ 		 * allocate page tables above the kernel. So we first map
+ 		 * [kernel_end, end) to make memory above the kernel be mapped
+ 		 * as soon as possible. And then use page tables allocated above
+ 		 * the kernel to map [ISA_END_ADDRESS, kernel_end).
+ 		 */
+ 		memory_map_bottom_up(kernel_end, end);
+ 		memory_map_bottom_up(ISA_END_ADDRESS, kernel_end);
+ 	} else {
+ 		memory_map_top_down(ISA_END_ADDRESS, end);
+ 	}
  
  #ifdef CONFIG_X86_64
  	if (max_pfn > max_low_pfn) {

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

^ permalink raw reply	[flat|nested] 112+ messages in thread

end of thread, other threads:[~2022-02-16  5:38 UTC | newest]

Thread overview: 112+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-08  7:48 linux-next: manual merge of the akpm-current tree with the tip tree Stephen Rothwell
2013-11-08 18:58 ` Josh Triplett
2013-11-08 23:20   ` Stephen Rothwell
2013-11-09  0:19     ` Josh Triplett
  -- strict thread matches above, loose matches on Subject: below --
2022-02-16  5:38 Stephen Rothwell
2021-10-07  6:27 Stephen Rothwell
2021-03-22  6:12 Stephen Rothwell
2020-12-11  8:56 Stephen Rothwell
2020-12-11 12:47 ` Jason Gunthorpe
2020-11-27  7:48 Stephen Rothwell
2020-11-27  7:39 Stephen Rothwell
2020-11-27 11:54 ` Andy Shevchenko
2020-11-30  9:27   ` Thomas Gleixner
2020-11-23  8:05 Stephen Rothwell
2020-11-09  6:00 Stephen Rothwell
2020-10-13  6:59 Stephen Rothwell
2020-07-17 10:19 Stephen Rothwell
2020-05-29 11:05 Stephen Rothwell
2020-05-29 10:18 Stephen Rothwell
2020-05-29 10:05 Stephen Rothwell
2020-05-29  9:58 Stephen Rothwell
2020-05-25 11:04 Stephen Rothwell
2020-05-26  4:41 ` Singh, Balbir
2020-06-03  4:43 ` Stephen Rothwell
2020-05-19 16:18 Stephen Rothwell
2020-03-25  7:48 Stephen Rothwell
2020-03-19  6:42 Stephen Rothwell
2020-01-20  6:37 Stephen Rothwell
2020-01-20  6:30 Stephen Rothwell
2019-10-31  5:43 Stephen Rothwell
2019-06-24 10:24 Stephen Rothwell
2019-05-01 11:10 Stephen Rothwell
2019-01-31  4:31 Stephen Rothwell
2018-08-20  4:32 Stephen Rothwell
2018-08-20 19:52 ` Andrew Morton
2018-03-23  5:59 Stephen Rothwell
2017-12-18  5:04 Stephen Rothwell
2017-11-10  4:33 Stephen Rothwell
2017-11-02  7:19 Stephen Rothwell
2017-08-22  6:57 Stephen Rothwell
2017-08-23  6:39 ` Vlastimil Babka
2017-08-11  7:53 Stephen Rothwell
2017-08-11  9:34 ` Peter Zijlstra
2017-08-11 10:48   ` Peter Zijlstra
2017-08-11 11:45   ` Stephen Rothwell
2017-08-11 11:56     ` Ingo Molnar
2017-08-11 12:17       ` Peter Zijlstra
2017-08-11 12:44         ` Ingo Molnar
2017-08-11 13:49           ` Stephen Rothwell
2017-08-11 14:04       ` Peter Zijlstra
2017-08-13  6:06         ` Nadav Amit
2017-08-13 12:50           ` Peter Zijlstra
2017-08-14  3:16             ` Minchan Kim
2017-08-14  5:07               ` Nadav Amit
2017-08-14  5:23                 ` Minchan Kim
2017-08-14  8:38                 ` Minchan Kim
2017-08-14 19:57                   ` Peter Zijlstra
2017-08-16  4:14                     ` Minchan Kim
2017-08-14 19:38                 ` Peter Zijlstra
2017-08-15  7:51                   ` Nadav Amit
2017-08-14  3:09         ` Minchan Kim
2017-08-14 18:54           ` Peter Zijlstra
2017-04-12  6:46 Stephen Rothwell
2017-04-12 20:53 ` Vlastimil Babka
2017-04-20  2:17   ` NeilBrown
2017-03-24  5:25 Stephen Rothwell
2017-02-17  4:40 Stephen Rothwell
2016-11-14  6:08 Stephen Rothwell
2016-07-29  4:14 Stephen Rothwell
2016-06-15  5:23 Stephen Rothwell
2016-06-18 19:39 ` Manfred Spraul
2016-04-29  6:12 Stephen Rothwell
2016-04-29  6:26 ` Ingo Molnar
2016-03-02  5:40 Stephen Rothwell
2016-02-26  5:07 Stephen Rothwell
2016-02-26 21:35 ` Andrew Morton
2016-02-19  4:09 Stephen Rothwell
2016-02-19 15:26 ` Ard Biesheuvel
2015-12-07  8:06 Stephen Rothwell
2015-10-02  4:21 Stephen Rothwell
2015-07-28  6:00 Stephen Rothwell
2015-07-29 17:12 ` Andrea Arcangeli
2015-07-29 17:47   ` Andy Lutomirski
2015-07-29 18:46     ` Thomas Gleixner
2015-07-30 15:38       ` Andrea Arcangeli
2015-07-29 23:06   ` Stephen Rothwell
2015-07-29 23:07     ` Thomas Gleixner
2015-09-07 23:35   ` Stephen Rothwell
2015-09-08 18:11     ` Linus Torvalds
2015-09-08 22:56       ` Stephen Rothwell
2015-09-08 23:03         ` Linus Torvalds
2015-09-08 23:21           ` Andrew Morton
2015-09-16  6:58             ` Geert Uytterhoeven
2015-06-04 12:07 Stephen Rothwell
2015-04-08  8:28 Stephen Rothwell
2015-04-08  8:25 Stephen Rothwell
2014-03-17  9:31 Stephen Rothwell
2014-03-17  9:36 ` Peter Zijlstra
2014-03-19 23:27   ` Andrew Morton
2014-01-14  4:53 Stephen Rothwell
2014-01-14  5:04 ` Davidlohr Bueso
2014-01-14 12:51 ` Peter Zijlstra
2014-01-14 13:17   ` Geert Uytterhoeven
2014-01-14 13:33     ` Peter Zijlstra
2014-01-14 16:19     ` H. Peter Anvin
2014-01-14 15:15   ` H. Peter Anvin
2014-01-14 15:20     ` Geert Uytterhoeven
2014-01-14 15:41       ` Peter Zijlstra
2014-01-14 15:48         ` H. Peter Anvin
2014-01-07  6:00 Stephen Rothwell
2014-01-07  6:34 ` Tang Chen
2013-10-30  6:40 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).