linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the rcu tree with the tip tree
@ 2011-06-20  4:47 Stephen Rothwell
  2011-06-20 15:17 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2011-06-20  4:47 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

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

Hi Paul,

Today's linux-next merge of the rcu tree got conflicts in
kernel/rcutree.c and kernel/rcutree_plugin.h between various commits from
the tip tree and various commits from the rcu tree.

I can't easily resolve these, so I have dropped the rcu tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2011-06-20  4:47 linux-next: manual merge of the rcu tree with the tip tree Stephen Rothwell
@ 2011-06-20 15:17 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2011-06-20 15:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

On Mon, Jun 20, 2011 at 02:47:05PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got conflicts in
> kernel/rcutree.c and kernel/rcutree_plugin.h between various commits from
> the tip tree and various commits from the rcu tree.
> 
> I can't easily resolve these, so I have dropped the rcu tree for today.

I will be resolving these shortly, please accept my apologies for the
hassle.

						Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2024-02-27  1:55 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2024-02-27  1:55 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Boqun Feng, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  Documentation/admin-guide/kernel-parameters.txt

between commit:

  5c5682b9f87a ("x86/cpu: Detect real BSP on crash kernels")

from the tip tree and commit:

  600716592a3a ("doc: Add EARLY flag to early-parsed kernel boot parameters")

from the rcu 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/kernel-parameters.txt
index fd1519ee44a0,3f894fbb4916..000000000000
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@@ -1099,7 -1101,16 +1100,7 @@@
  			Disable TLBIE instruction. Currently does not work
  			with KVM, with HASH MMU, or with coherent accelerators.
  
- 	disable_ddw	[PPC/PSERIES]
 -	disable_cpu_apicid= [X86,APIC,SMP]
 -			Format: <int>
 -			The number of initial APIC ID for the
 -			corresponding CPU to be disabled at boot,
 -			mostly used for the kdump 2nd kernel to
 -			disable BSP to wake up multiple CPUs without
 -			causing system reset or hang due to sending
 -			INIT from AP to BSP.
 -
+ 	disable_ddw	[PPC/PSERIES,EARLY]
  			Disable Dynamic DMA Window support. Use this
  			to workaround buggy firmware.
  
@@@ -1744,18 -1749,7 +1745,18 @@@
  				(that will set all pages holding image data
  				during restoration read-only).
  
 +	hibernate.compressor= 	[HIBERNATION] Compression algorithm to be
 +				used with hibernation.
 +				Format: { lzo | lz4 }
 +				Default: lzo
 +
 +				lzo: Select LZO compression algorithm to
 +				compress/decompress hibernation image.
 +
 +				lz4: Select LZ4 compression algorithm to
 +				compress/decompress hibernation image.
 +
- 	highmem=nn[KMG]	[KNL,BOOT] forces the highmem zone to have an exact
+ 	highmem=nn[KMG]	[KNL,BOOT,EARLY] forces the highmem zone to have an exact
  			size of <nn>. This works even on boxes that have no
  			highmem otherwise. This also works to reduce highmem
  			size on bigger boxes.

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2022-04-06  2:45 Stephen Rothwell
@ 2022-04-06 16:28 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2022-04-06 16:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Frederic Weisbecker, Linux Kernel Mailing List,
	Linux Next Mailing List, Valentin Schneider

On Wed, Apr 06, 2022 at 12:45:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got conflicts in:
> 
>   kernel/sched/core.c
>   include/linux/sched.h
> 
> between commit:
> 
>   cfe43f478b79 ("preempt/dynamic: Introduce preemption model accessors")
> 
> from the tip tree and commit:
> 
>   42e3e3c6a774 ("EXP preempt/dynamic: Introduce preempt mode accessors")
> 
> from the rcu tree.
> 
> Well, this is just a pain.  Paul, please don't put expierimental things
> in you linuc-nect included branch.  I have dropped the rcu tree today.

Gah!  Please accept my apologies for the hassle!

In the short term, I have reset rcu/next to the commit preceding
42e3e3c6a774 ("EXP preempt/dynamic: Introduce preempt mode accessors").
This could cause some trouble for a few corner-case -next users, but...

Longer term, this is excellent news, because it means that I can drop
that commit from my tree entirely and rebase my stack on top of the
version of that same commit that is just now in -tip.

> The rules I use for the linux-next tree are:
> 
> "You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
>         Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and 
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary."

Understood, and thank you.

The next time that I am forced to choose between propagating a bug into
-next on the one hand and precisely following the above rules on the
other, I will consult with you beforehand.  Please accept my apologies
for failing to have done so this time.

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2022-04-06  2:45 Stephen Rothwell
  2022-04-06 16:28 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2022-04-06  2:45 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Frederic Weisbecker, Linux Kernel Mailing List,
	Linux Next Mailing List, Valentin Schneider

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

Hi all,

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

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

between commit:

  cfe43f478b79 ("preempt/dynamic: Introduce preemption model accessors")

from the tip tree and commit:

  42e3e3c6a774 ("EXP preempt/dynamic: Introduce preempt mode accessors")

from the rcu tree.

Well, this is just a pain.  Paul, please don't put expierimental things
in you linuc-nect included branch.  I have dropped the rcu tree today.

The rules I use for the linux-next tree are:

"You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary."

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

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2022-02-21 18:17 broonie
  0 siblings, 0 replies; 71+ messages in thread
From: broonie @ 2022-02-21 18:17 UTC (permalink / raw)
  To: Paul E . McKenney
  Cc: Frederic Weisbecker, Linux Kernel Mailing List,
	Linux Next Mailing List, Peter Zijlstra, Yury Norov

Hi all,

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

  kernel/rcu/tree_plugin.h

between commit:

  04d4e665a6090 ("sched/isolation: Use single feature type while referring to housekeeping cpumask")

from the tip tree and commit:

  6a2c1d450a6a3 ("rcu: Replace cpumask_weight with cpumask_empty where appropriate")

from the rcu 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.

diff --cc kernel/rcu/tree_plugin.h
index 65f25a32f6d75,6b9bcd45c7b21..0000000000000
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@@ -1214,10 -1219,11 +1219,11 @@@ static void rcu_boost_kthread_setaffini
  		if ((mask & leaf_node_cpu_bit(rnp, cpu)) &&
  		    cpu != outgoingcpu)
  			cpumask_set_cpu(cpu, cm);
 -	cpumask_and(cm, cm, housekeeping_cpumask(HK_FLAG_RCU));
 +	cpumask_and(cm, cm, housekeeping_cpumask(HK_TYPE_RCU));
- 	if (cpumask_weight(cm) == 0)
+ 	if (cpumask_empty(cm))
 -		cpumask_copy(cm, housekeeping_cpumask(HK_FLAG_RCU));
 +		cpumask_copy(cm, housekeeping_cpumask(HK_TYPE_RCU));
  	set_cpus_allowed_ptr(t, cm);
+ 	mutex_unlock(&rnp->boost_kthread_mutex);
  	free_cpumask_var(cm);
  }
  

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2021-10-12  4:48 Stephen Rothwell
@ 2021-10-13 16:31 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2021-10-13 16:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 12, 2021 at 03:48:28PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tasks.h
> 
> between commit:
> 
>   9b3c4ab3045e ("sched,rcu: Rework try_invoke_on_locked_down_task()")
> 
> from the tip tree and commit:
> 
>   18f08e758f34 ("rcu-tasks: Add trc_inspect_reader() checks for exiting critical section")
> 
> from the rcu tree.
> 
> I fixed it up (I hope - 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.

Thank you for catching this!  I have it down for my upcoming pull
request.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tasks.h
> index 171bc848e8e3,e4a32db9f712..000000000000
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@@ -928,10 -919,10 +919,10 @@@ reset_ipi
>   }
>   
>   /* Callback function for scheduler to check locked-down task.  */
>  -static bool trc_inspect_reader(struct task_struct *t, void *arg)
>  +static int trc_inspect_reader(struct task_struct *t, void *arg)
>   {
>   	int cpu = task_cpu(t);
> - 	bool in_qs = false;
> + 	int nesting;
>   	bool ofl = cpu_is_offline(cpu);
>   
>   	if (task_curr(t)) {
> @@@ -951,18 -942,18 +942,18 @@@
>   		n_heavy_reader_updates++;
>   		if (ofl)
>   			n_heavy_reader_ofl_updates++;
> - 		in_qs = true;
> + 		nesting = 0;
>   	} else {
>   		// The task is not running, so C-language access is safe.
> - 		in_qs = likely(!t->trc_reader_nesting);
> + 		nesting = t->trc_reader_nesting;
>   	}
>   
> - 	// Mark as checked so that the grace-period kthread will
> - 	// remove it from the holdout list.
> - 	t->trc_reader_checked = true;
> - 
> - 	if (in_qs)
> - 		return 0;  // Already in quiescent state, done!!!
> + 	// If not exiting a read-side critical section, mark as checked
> + 	// so that the grace-period kthread will remove it from the
> + 	// holdout list.
> + 	t->trc_reader_checked = nesting >= 0;
> + 	if (nesting <= 0)
>  -		return !nesting;  // If in QS, done, otherwise try again later.
> ++		return (!nesting) ? 0 : -EINVAL;  // If in QS, done, otherwise try again later.
>   
>   	// The task is in a read-side critical section, so set up its
>   	// state so that it will awaken the grace-period kthread upon exit



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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2021-10-12  4:48 Stephen Rothwell
  2021-10-13 16:31 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2021-10-12  4:48 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  kernel/rcu/tasks.h

between commit:

  9b3c4ab3045e ("sched,rcu: Rework try_invoke_on_locked_down_task()")

from the tip tree and commit:

  18f08e758f34 ("rcu-tasks: Add trc_inspect_reader() checks for exiting critical section")

from the rcu tree.

I fixed it up (I hope - 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/rcu/tasks.h
index 171bc848e8e3,e4a32db9f712..000000000000
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@@ -928,10 -919,10 +919,10 @@@ reset_ipi
  }
  
  /* Callback function for scheduler to check locked-down task.  */
 -static bool trc_inspect_reader(struct task_struct *t, void *arg)
 +static int trc_inspect_reader(struct task_struct *t, void *arg)
  {
  	int cpu = task_cpu(t);
- 	bool in_qs = false;
+ 	int nesting;
  	bool ofl = cpu_is_offline(cpu);
  
  	if (task_curr(t)) {
@@@ -951,18 -942,18 +942,18 @@@
  		n_heavy_reader_updates++;
  		if (ofl)
  			n_heavy_reader_ofl_updates++;
- 		in_qs = true;
+ 		nesting = 0;
  	} else {
  		// The task is not running, so C-language access is safe.
- 		in_qs = likely(!t->trc_reader_nesting);
+ 		nesting = t->trc_reader_nesting;
  	}
  
- 	// Mark as checked so that the grace-period kthread will
- 	// remove it from the holdout list.
- 	t->trc_reader_checked = true;
- 
- 	if (in_qs)
- 		return 0;  // Already in quiescent state, done!!!
+ 	// If not exiting a read-side critical section, mark as checked
+ 	// so that the grace-period kthread will remove it from the
+ 	// holdout list.
+ 	t->trc_reader_checked = nesting >= 0;
+ 	if (nesting <= 0)
 -		return !nesting;  // If in QS, done, otherwise try again later.
++		return (!nesting) ? 0 : -EINVAL;  // If in QS, done, otherwise try again later.
  
  	// The task is in a read-side critical section, so set up its
  	// state so that it will awaken the grace-period kthread upon exit

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2021-08-17  7:09 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2021-08-17  7:09 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  kernel/time/tick-internal.h

between commits:

  8c3b5e6ec0fe ("hrtimer: Ensure timerfd notification for HIGHRES=n")
  a761a67f591a ("timekeeping: Distangle resume and clock-was-set events")
  17a1b8826b45 ("hrtimer: Add bases argument to clock_was_set()")

from the tip tree and commit:

  a5e8561a2bdf ("clocksource: Make clocksource-wdtest.c safe for slow-HZ systems")

from the rcu 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/time/tick-internal.h
index 3548f0829e6d,5459bab2f4f7..000000000000
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@@ -166,14 -166,22 +166,34 @@@ DECLARE_PER_CPU(struct hrtimer_cpu_base
  extern u64 get_next_timer_interrupt(unsigned long basej, u64 basem);
  void timer_clear_idle(void);
  
 +#define CLOCK_SET_WALL							\
 +	(BIT(HRTIMER_BASE_REALTIME) | BIT(HRTIMER_BASE_REALTIME_SOFT) |	\
 +	 BIT(HRTIMER_BASE_TAI) | BIT(HRTIMER_BASE_TAI_SOFT))
 +
 +#define CLOCK_SET_BOOT							\
 +	(BIT(HRTIMER_BASE_BOOTTIME) | BIT(HRTIMER_BASE_BOOTTIME_SOFT))
 +
 +void clock_was_set(unsigned int bases);
 +void clock_was_set_delayed(void);
 +
 +void hrtimers_resume_local(void);
++
+ /* Since jiffies uses a simple TICK_NSEC multiplier
+  * conversion, the .shift value could be zero. However
+  * this would make NTP adjustments impossible as they are
+  * in units of 1/2^.shift. Thus we use JIFFIES_SHIFT to
+  * shift both the nominator and denominator the same
+  * amount, and give ntp adjustments in units of 1/2^8
+  *
+  * The value 8 is somewhat carefully chosen, as anything
+  * larger can result in overflows. TICK_NSEC grows as HZ
+  * shrinks, so values greater than 8 overflow 32bits when
+  * HZ=100.
+  */
+ #if HZ < 34
+ #define JIFFIES_SHIFT	6
+ #elif HZ < 67
+ #define JIFFIES_SHIFT	7
+ #else
+ #define JIFFIES_SHIFT	8
+ #endif

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2021-06-23  5:33 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2021-06-23  5:33 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  kernel/rcu/tree_stall.h

between commit:

  2f064a59a11f ("sched: Change task_struct::state")

from the tip tree and commit:

  e44111ed20d8 ("rcu: Add ->rt_priority and ->gp_start to show_rcu_gp_kthreads() output")

from the rcu 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/rcu/tree_stall.h
index acb2288063b5,be648ab03906..000000000000
--- a/kernel/rcu/tree_stall.h
+++ b/kernel/rcu/tree_stall.h
@@@ -734,21 -817,30 +817,30 @@@ void show_rcu_gp_kthreads(void
  	j = jiffies;
  	ja = j - data_race(rcu_state.gp_activity);
  	jr = j - data_race(rcu_state.gp_req_activity);
+ 	js = j - data_race(rcu_state.gp_start);
  	jw = j - data_race(rcu_state.gp_wake_time);
- 	pr_info("%s: wait state: %s(%d) ->state: %#x delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
 -	pr_info("%s: wait state: %s(%d) ->state: %#lx ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
++	pr_info("%s: wait state: %s(%d) ->state: %#x ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
  		rcu_state.name, gp_state_getname(rcu_state.gp_state),
- 		rcu_state.gp_state, t ? t->__state : 0x1ffff,
- 		ja, jr, jw, (long)data_race(rcu_state.gp_wake_seq),
 -		rcu_state.gp_state, t ? t->state : 0x1ffffL, t ? t->rt_priority : 0xffU,
++		rcu_state.gp_state, t ? t->__state : 0x1ffff, t ? t->rt_priority : 0xffU,
+ 		js, ja, jr, jw, (long)data_race(rcu_state.gp_wake_seq),
  		(long)data_race(rcu_state.gp_seq),
  		(long)data_race(rcu_get_root()->gp_seq_needed),
+ 		data_race(rcu_state.gp_max),
  		data_race(rcu_state.gp_flags));
  	rcu_for_each_node_breadth_first(rnp) {
- 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq),
- 				 READ_ONCE(rnp->gp_seq_needed)))
+ 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq), READ_ONCE(rnp->gp_seq_needed)) &&
+ 		    !data_race(rnp->qsmask) && !data_race(rnp->boost_tasks) &&
+ 		    !data_race(rnp->exp_tasks) && !data_race(rnp->gp_tasks))
  			continue;
- 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n",
- 			rnp->grplo, rnp->grphi, (long)data_race(rnp->gp_seq),
- 			(long)data_race(rnp->gp_seq_needed));
+ 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld ->qsmask %#lx %c%c%c%c ->n_boosts %ld\n",
+ 			rnp->grplo, rnp->grphi,
+ 			(long)data_race(rnp->gp_seq), (long)data_race(rnp->gp_seq_needed),
+ 			data_race(rnp->qsmask),
+ 			".b"[!!data_race(rnp->boost_kthread_task)],
+ 			".B"[!!data_race(rnp->boost_tasks)],
+ 			".E"[!!data_race(rnp->exp_tasks)],
+ 			".G"[!!data_race(rnp->gp_tasks)],
+ 			data_race(rnp->n_boosts));
  		if (!rcu_is_leaf_node(rnp))
  			continue;
  		for_each_leaf_node_possible_cpu(rnp, cpu) {

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2021-06-22  4:47 Stephen Rothwell
  2021-06-22  5:04 ` Stephen Rothwell
@ 2021-06-22 17:10 ` Paul E. McKenney
  1 sibling, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2021-06-22 17:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Jun 22, 2021 at 02:47:57PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree_stall.h
> 
> between commit:
> 
>   2f064a59a11f ("sched: Change task_struct::state")
> 
> from the tip tree and commit:
> 
>   367455053a76 ("rcu: Mark accesses in tree_stall.h")
> 
> from the rcu 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.

I have moved this RCU commit out of my -next pile.  I will put it back
at v5.14-rc1 time.  The other conflict looks quite straightforward,
so I am leaving that one be.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree_stall.h
> index acb2288063b5,24065f1acb8b..000000000000
> --- a/kernel/rcu/tree_stall.h
> +++ b/kernel/rcu/tree_stall.h
> @@@ -460,12 -462,13 +462,13 @@@ static void rcu_check_gp_kthread_starva
>   
>   	if (rcu_is_gp_kthread_starving(&j)) {
>   		cpu = gpk ? task_cpu(gpk) : -1;
>  -		pr_err("%s kthread starved for %ld jiffies! g%ld f%#x %s(%d) ->state=%#lx ->cpu=%d\n",
>  +		pr_err("%s kthread starved for %ld jiffies! g%ld f%#x %s(%d) ->state=%#x ->cpu=%d\n",
>   		       rcu_state.name, j,
>   		       (long)rcu_seq_current(&rcu_state.gp_seq),
> - 		       data_race(rcu_state.gp_flags),
> - 		       gp_state_getname(rcu_state.gp_state), rcu_state.gp_state,
> - 		       gpk ? gpk->__state : ~0, cpu);
> + 		       data_race(READ_ONCE(rcu_state.gp_flags)),
> + 		       gp_state_getname(rcu_state.gp_state),
> + 		       data_race(READ_ONCE(rcu_state.gp_state)),
>  -		       gpk ? data_race(READ_ONCE(gpk->state)) : ~0, cpu);
> ++		       gpk ? data_race(READ_ONCE(gpk->__state)) : ~0, cpu);
>   		if (gpk) {
>   			pr_err("\tUnless %s kthread gets sufficient CPU time, OOM is now expected behavior.\n", rcu_state.name);
>   			pr_err("RCU grace-period kthread stack dump:\n");
> @@@ -508,7 -511,7 +511,7 @@@ static void rcu_check_gp_kthread_expire
>   		       (long)rcu_seq_current(&rcu_state.gp_seq),
>   		       data_race(rcu_state.gp_flags),
>   		       gp_state_getname(RCU_GP_WAIT_FQS), RCU_GP_WAIT_FQS,
> - 		       gpk->__state);
>  -		       data_race(READ_ONCE(gpk->state)));
> ++		       data_race(READ_ONCE(gpk->__state)));
>   		pr_err("\tPossible timer handling issue on cpu=%d timer-softirq=%u\n",
>   		       cpu, kstat_softirqs_cpu(TIMER_SOFTIRQ, cpu));
>   	}
> @@@ -732,23 -816,34 +816,34 @@@ void show_rcu_gp_kthreads(void
>   	struct task_struct *t = READ_ONCE(rcu_state.gp_kthread);
>   
>   	j = jiffies;
> - 	ja = j - data_race(rcu_state.gp_activity);
> - 	jr = j - data_race(rcu_state.gp_req_activity);
> - 	jw = j - data_race(rcu_state.gp_wake_time);
> - 	pr_info("%s: wait state: %s(%d) ->state: %#x delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
> + 	ja = j - data_race(READ_ONCE(rcu_state.gp_activity));
> + 	jr = j - data_race(READ_ONCE(rcu_state.gp_req_activity));
> + 	js = j - data_race(READ_ONCE(rcu_state.gp_start));
> + 	jw = j - data_race(READ_ONCE(rcu_state.gp_wake_time));
>  -	pr_info("%s: wait state: %s(%d) ->state: %#lx ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
> ++	pr_info("%s: wait state: %s(%d) ->state: %#x ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
>   		rcu_state.name, gp_state_getname(rcu_state.gp_state),
> - 		rcu_state.gp_state, t ? t->__state : 0x1ffff,
> - 		ja, jr, jw, (long)data_race(rcu_state.gp_wake_seq),
> - 		(long)data_race(rcu_state.gp_seq),
> - 		(long)data_race(rcu_get_root()->gp_seq_needed),
> - 		data_race(rcu_state.gp_flags));
> + 		data_race(READ_ONCE(rcu_state.gp_state)),
>  -		t ? data_race(READ_ONCE(t->state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
> ++		t ? data_race(READ_ONCE(t->__state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
> + 		js, ja, jr, jw, (long)data_race(READ_ONCE(rcu_state.gp_wake_seq)),
> + 		(long)data_race(READ_ONCE(rcu_state.gp_seq)),
> + 		(long)data_race(READ_ONCE(rcu_get_root()->gp_seq_needed)),
> + 		data_race(READ_ONCE(rcu_state.gp_max)),
> + 		data_race(READ_ONCE(rcu_state.gp_flags)));
>   	rcu_for_each_node_breadth_first(rnp) {
> - 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq),
> - 				 READ_ONCE(rnp->gp_seq_needed)))
> + 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq), READ_ONCE(rnp->gp_seq_needed)) &&
> + 		    !data_race(READ_ONCE(rnp->qsmask)) && !data_race(READ_ONCE(rnp->boost_tasks)) &&
> + 		    !data_race(READ_ONCE(rnp->exp_tasks)) && !data_race(READ_ONCE(rnp->gp_tasks)))
>   			continue;
> - 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n",
> - 			rnp->grplo, rnp->grphi, (long)data_race(rnp->gp_seq),
> - 			(long)data_race(rnp->gp_seq_needed));
> + 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld ->qsmask %#lx %c%c%c%c ->n_boosts %ld\n",
> + 			rnp->grplo, rnp->grphi,
> + 			(long)data_race(READ_ONCE(rnp->gp_seq)),
> + 			(long)data_race(READ_ONCE(rnp->gp_seq_needed)),
> + 			data_race(READ_ONCE(rnp->qsmask)),
> + 			".b"[!!data_race(READ_ONCE(rnp->boost_kthread_task))],
> + 			".B"[!!data_race(READ_ONCE(rnp->boost_tasks))],
> + 			".E"[!!data_race(READ_ONCE(rnp->exp_tasks))],
> + 			".G"[!!data_race(READ_ONCE(rnp->gp_tasks))],
> + 			data_race(READ_ONCE(rnp->n_boosts)));
>   		if (!rcu_is_leaf_node(rnp))
>   			continue;
>   		for_each_leaf_node_possible_cpu(rnp, cpu) {



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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2021-06-22  4:47 Stephen Rothwell
@ 2021-06-22  5:04 ` Stephen Rothwell
  2021-06-22 17:10 ` Paul E. McKenney
  1 sibling, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2021-06-22  5:04 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Tue, 22 Jun 2021 14:47:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> @@@ -732,23 -816,34 +816,34 @@@ void show_rcu_gp_kthreads(void
>   	struct task_struct *t = READ_ONCE(rcu_state.gp_kthread);
>   
>   	j = jiffies;
> - 	ja = j - data_race(rcu_state.gp_activity);
> - 	jr = j - data_race(rcu_state.gp_req_activity);
> - 	jw = j - data_race(rcu_state.gp_wake_time);
> - 	pr_info("%s: wait state: %s(%d) ->state: %#x delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
> + 	ja = j - data_race(READ_ONCE(rcu_state.gp_activity));
> + 	jr = j - data_race(READ_ONCE(rcu_state.gp_req_activity));
> + 	js = j - data_race(READ_ONCE(rcu_state.gp_start));
> + 	jw = j - data_race(READ_ONCE(rcu_state.gp_wake_time));
>  -	pr_info("%s: wait state: %s(%d) ->state: %#lx ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
> ++	pr_info("%s: wait state: %s(%d) ->state: %#x ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
>   		rcu_state.name, gp_state_getname(rcu_state.gp_state),
> - 		rcu_state.gp_state, t ? t->__state : 0x1ffff,
> - 		ja, jr, jw, (long)data_race(rcu_state.gp_wake_seq),
> - 		(long)data_race(rcu_state.gp_seq),
> - 		(long)data_race(rcu_get_root()->gp_seq_needed),
> - 		data_race(rcu_state.gp_flags));
> + 		data_race(READ_ONCE(rcu_state.gp_state)),
>  -		t ? data_race(READ_ONCE(t->state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
> ++		t ? data_race(READ_ONCE(t->__state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
                                                              ^
I missed removing this 'L' the first time, but have fixed it up now.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2021-06-22  4:51 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2021-06-22  4:51 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Frederic Weisbecker, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  kernel/rcu/tree_plugin.h

between commit:

  b03fbd4ff24c ("sched: Introduce task_is_running()")

from the tip tree and commit:

  9f460390aac1 ("rcu/nocb: Start moving nocb code to its own plugin file")

from the rcu tree.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Jun 2021 14:49:27 +1000
Subject: [PATCH] fix for code movement to kernel/rcu/tree_nocb.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/rcu/tree_nocb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
index bf2690ca5d2b..8fdf44f8523f 100644
--- a/kernel/rcu/tree_nocb.h
+++ b/kernel/rcu/tree_nocb.h
@@ -1311,7 +1311,7 @@ EXPORT_SYMBOL_GPL(rcu_bind_current_to_nocb);
 #ifdef CONFIG_SMP
 static char *show_rcu_should_be_on_cpu(struct task_struct *tsp)
 {
-	return tsp && tsp->state == TASK_RUNNING && !tsp->on_cpu ? "!" : "";
+	return tsp && task_is_running(tsp) && !tsp->on_cpu ? "!" : "";
 }
 #else // #ifdef CONFIG_SMP
 static char *show_rcu_should_be_on_cpu(struct task_struct *tsp)
-- 
2.30.2

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2021-06-22  4:47 Stephen Rothwell
  2021-06-22  5:04 ` Stephen Rothwell
  2021-06-22 17:10 ` Paul E. McKenney
  0 siblings, 2 replies; 71+ messages in thread
From: Stephen Rothwell @ 2021-06-22  4:47 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  kernel/rcu/tree_stall.h

between commit:

  2f064a59a11f ("sched: Change task_struct::state")

from the tip tree and commit:

  367455053a76 ("rcu: Mark accesses in tree_stall.h")

from the rcu 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/rcu/tree_stall.h
index acb2288063b5,24065f1acb8b..000000000000
--- a/kernel/rcu/tree_stall.h
+++ b/kernel/rcu/tree_stall.h
@@@ -460,12 -462,13 +462,13 @@@ static void rcu_check_gp_kthread_starva
  
  	if (rcu_is_gp_kthread_starving(&j)) {
  		cpu = gpk ? task_cpu(gpk) : -1;
 -		pr_err("%s kthread starved for %ld jiffies! g%ld f%#x %s(%d) ->state=%#lx ->cpu=%d\n",
 +		pr_err("%s kthread starved for %ld jiffies! g%ld f%#x %s(%d) ->state=%#x ->cpu=%d\n",
  		       rcu_state.name, j,
  		       (long)rcu_seq_current(&rcu_state.gp_seq),
- 		       data_race(rcu_state.gp_flags),
- 		       gp_state_getname(rcu_state.gp_state), rcu_state.gp_state,
- 		       gpk ? gpk->__state : ~0, cpu);
+ 		       data_race(READ_ONCE(rcu_state.gp_flags)),
+ 		       gp_state_getname(rcu_state.gp_state),
+ 		       data_race(READ_ONCE(rcu_state.gp_state)),
 -		       gpk ? data_race(READ_ONCE(gpk->state)) : ~0, cpu);
++		       gpk ? data_race(READ_ONCE(gpk->__state)) : ~0, cpu);
  		if (gpk) {
  			pr_err("\tUnless %s kthread gets sufficient CPU time, OOM is now expected behavior.\n", rcu_state.name);
  			pr_err("RCU grace-period kthread stack dump:\n");
@@@ -508,7 -511,7 +511,7 @@@ static void rcu_check_gp_kthread_expire
  		       (long)rcu_seq_current(&rcu_state.gp_seq),
  		       data_race(rcu_state.gp_flags),
  		       gp_state_getname(RCU_GP_WAIT_FQS), RCU_GP_WAIT_FQS,
- 		       gpk->__state);
 -		       data_race(READ_ONCE(gpk->state)));
++		       data_race(READ_ONCE(gpk->__state)));
  		pr_err("\tPossible timer handling issue on cpu=%d timer-softirq=%u\n",
  		       cpu, kstat_softirqs_cpu(TIMER_SOFTIRQ, cpu));
  	}
@@@ -732,23 -816,34 +816,34 @@@ void show_rcu_gp_kthreads(void
  	struct task_struct *t = READ_ONCE(rcu_state.gp_kthread);
  
  	j = jiffies;
- 	ja = j - data_race(rcu_state.gp_activity);
- 	jr = j - data_race(rcu_state.gp_req_activity);
- 	jw = j - data_race(rcu_state.gp_wake_time);
- 	pr_info("%s: wait state: %s(%d) ->state: %#x delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
+ 	ja = j - data_race(READ_ONCE(rcu_state.gp_activity));
+ 	jr = j - data_race(READ_ONCE(rcu_state.gp_req_activity));
+ 	js = j - data_race(READ_ONCE(rcu_state.gp_start));
+ 	jw = j - data_race(READ_ONCE(rcu_state.gp_wake_time));
 -	pr_info("%s: wait state: %s(%d) ->state: %#lx ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
++	pr_info("%s: wait state: %s(%d) ->state: %#x ->rt_priority %u delta ->gp_start %lu ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_max %lu ->gp_flags %#x\n",
  		rcu_state.name, gp_state_getname(rcu_state.gp_state),
- 		rcu_state.gp_state, t ? t->__state : 0x1ffff,
- 		ja, jr, jw, (long)data_race(rcu_state.gp_wake_seq),
- 		(long)data_race(rcu_state.gp_seq),
- 		(long)data_race(rcu_get_root()->gp_seq_needed),
- 		data_race(rcu_state.gp_flags));
+ 		data_race(READ_ONCE(rcu_state.gp_state)),
 -		t ? data_race(READ_ONCE(t->state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
++		t ? data_race(READ_ONCE(t->__state)) : 0x1ffffL, t ? t->rt_priority : 0xffU,
+ 		js, ja, jr, jw, (long)data_race(READ_ONCE(rcu_state.gp_wake_seq)),
+ 		(long)data_race(READ_ONCE(rcu_state.gp_seq)),
+ 		(long)data_race(READ_ONCE(rcu_get_root()->gp_seq_needed)),
+ 		data_race(READ_ONCE(rcu_state.gp_max)),
+ 		data_race(READ_ONCE(rcu_state.gp_flags)));
  	rcu_for_each_node_breadth_first(rnp) {
- 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq),
- 				 READ_ONCE(rnp->gp_seq_needed)))
+ 		if (ULONG_CMP_GE(READ_ONCE(rcu_state.gp_seq), READ_ONCE(rnp->gp_seq_needed)) &&
+ 		    !data_race(READ_ONCE(rnp->qsmask)) && !data_race(READ_ONCE(rnp->boost_tasks)) &&
+ 		    !data_race(READ_ONCE(rnp->exp_tasks)) && !data_race(READ_ONCE(rnp->gp_tasks)))
  			continue;
- 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n",
- 			rnp->grplo, rnp->grphi, (long)data_race(rnp->gp_seq),
- 			(long)data_race(rnp->gp_seq_needed));
+ 		pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld ->qsmask %#lx %c%c%c%c ->n_boosts %ld\n",
+ 			rnp->grplo, rnp->grphi,
+ 			(long)data_race(READ_ONCE(rnp->gp_seq)),
+ 			(long)data_race(READ_ONCE(rnp->gp_seq_needed)),
+ 			data_race(READ_ONCE(rnp->qsmask)),
+ 			".b"[!!data_race(READ_ONCE(rnp->boost_kthread_task))],
+ 			".B"[!!data_race(READ_ONCE(rnp->boost_tasks))],
+ 			".E"[!!data_race(READ_ONCE(rnp->exp_tasks))],
+ 			".G"[!!data_race(READ_ONCE(rnp->gp_tasks))],
+ 			data_race(READ_ONCE(rnp->n_boosts)));
  		if (!rcu_is_leaf_node(rnp))
  			continue;
  		for_each_leaf_node_possible_cpu(rnp, cpu) {

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-10-09  4:59 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2020-10-09  4:59 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  include/linux/lockdep.h

between commit:

  a046a86082cc ("lockdep: Fix lockdep recursion")

from the tip tree and commit:

  0eb8743dc570 ("lockdep: Cleanup PREEMPT_COUNT leftovers")

from the rcu 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/lockdep.h
index f5594879175a,8555fd128ebf..000000000000
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@@ -580,18 -566,16 +586,16 @@@ do {									
  
  #define lockdep_assert_preemption_enabled()				\
  do {									\
- 	WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)	&&		\
- 		     __lockdep_enabled			&&		\
 -	WARN_ON_ONCE(debug_locks			&&		\
++	WARN_ON_ONCE(__lockdep_enabled			&&		\
  		     (preempt_count() != 0		||		\
 -		      !raw_cpu_read(hardirqs_enabled)));		\
 +		      !this_cpu_read(hardirqs_enabled)));		\
  } while (0)
  
  #define lockdep_assert_preemption_disabled()				\
  do {									\
- 	WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)	&&		\
- 		     __lockdep_enabled			&&		\
 -	WARN_ON_ONCE(debug_locks			&&		\
++	WARN_ON_ONCE(__lockdep_enabled			&&		\
  		     (preempt_count() == 0		&&		\
 -		      raw_cpu_read(hardirqs_enabled)));			\
 +		      this_cpu_read(hardirqs_enabled)));		\
  } while (0)
  
  #else

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-07-29  6:23 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2020-07-29  6:23 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  arch/x86/entry/common.c

between commit:

  bdcd178ada90 ("x86/entry: Use generic interrupt entry/exit code")

from the tip tree and commit:

  20f165b7d2c8 ("rcu: Remove unused __rcu_is_watching() function")

from the rcu tree.

I fixed it up (the former removed that comment that the latter updated)
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] 71+ messages in thread

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-06-26  3:14 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2020-06-26  3:14 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  include/linux/compiler.h

between commit:

  1d8fcbb76bb1 ("compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header")

from the tip tree and commit:

  3b9946ebaf2b ("rcu: Fixup noinstr warnings")

from the rcu tree.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Jun 2020 13:02:03 +1000
Subject: [PATCH] merge fix for "rcu: Fixup noinstr warnings"

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

diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h
index 19cba99342c2..83d9a3c5204f 100644
--- a/include/linux/instrumentation.h
+++ b/include/linux/instrumentation.h
@@ -6,7 +6,7 @@
 
 /* Begin/end of an instrumentation safe region */
 #define instrumentation_begin() ({					\
-	asm volatile("%c0:\n\t"						\
+	asm volatile("%c0: nop\n\t"					\
 		     ".pushsection .discard.instr_begin\n\t"		\
 		     ".long %c0b - .\n\t"				\
 		     ".popsection\n\t" : : "i" (__COUNTER__));		\
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-06-25  2:44 Stephen Rothwell
@ 2020-06-25  3:44 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2020-06-25  3:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Jun 25, 2020 at 12:44:52PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   include/linux/smp.h
> 
> between commit:
> 
>   380dc20ce843 ("smp, irq_work: Continue smp_call_function*() and irq_work*() integration")
> 
> from the tip tree and commit:
> 
>   7effc6f7b465 ("EXP kernel/smp: Provide CSD lock timeout diagnostics")
> 
> from the rcu tree.
> 
> I have no idea how to fix this up ...

I have an interesting forward-port in my future, it seems.

> I fixed it up (I just effectively reverted the rcu tree commit) 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.

For the time being, I will move this out of my rcu/next pile.

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-06-25  2:44 Stephen Rothwell
  2020-06-25  3:44 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2020-06-25  2:44 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  include/linux/smp.h

between commit:

  380dc20ce843 ("smp, irq_work: Continue smp_call_function*() and irq_work*() integration")

from the tip tree and commit:

  7effc6f7b465 ("EXP kernel/smp: Provide CSD lock timeout diagnostics")

from the rcu tree.

I have no idea how to fix this up ...

I fixed it up (I just effectively reverted the rcu tree commit) 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] 71+ messages in thread

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-06-24  3:04 Stephen Rothwell
@ 2020-06-24  4:06 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2020-06-24  4:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Jun 24, 2020 at 01:04:50PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/sched/core.c
> 
> between commit:
> 
>   964ed98b0752 ("sched/core: Fix ttwu() race")
> 
> from the tip tree and commit:
> 
>   3c88d09bfb1b ("EXP sched: Alleged fix for v5.8 merge-window scheduler issue")
> 
> from the rcu tree.
> 
> I fixed it up (I used the version from the tip tree) 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.

Gah.  I will move my copy of this patch out of the rcu/next batch.
I included it so that I could find other bugs.  ;-)

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-06-24  3:04 Stephen Rothwell
  2020-06-24  4:06 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2020-06-24  3:04 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  kernel/sched/core.c

between commit:

  964ed98b0752 ("sched/core: Fix ttwu() race")

from the tip tree and commit:

  3c88d09bfb1b ("EXP sched: Alleged fix for v5.8 merge-window scheduler issue")

from the rcu tree.

I fixed it up (I used the version from the tip tree) 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] 71+ messages in thread

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-05-29 14:15   ` Paul E. McKenney
@ 2020-05-29 23:38     ` Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2020-05-29 23:38 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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

Hi Paul,

On Fri, 29 May 2020 07:15:01 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> Given that the merge window might be opening in a couple days, my thought
> is to defer these -rcu commits to my v5.9 pile, and then I resolve this
> conflict in the -rcu tree when v5.8-rc1 comes out.  I just now adjusted
> the -rcu tree's rcu/next branch accordingly.
> 
> Seem reasonable?

Sure, thanks.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-05-29  6:41 ` Stephen Rothwell
@ 2020-05-29 14:15   ` Paul E. McKenney
  2020-05-29 23:38     ` Stephen Rothwell
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2020-05-29 14:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

On Fri, May 29, 2020 at 04:41:32PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 29 May 2020 16:22:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> > 
> > Today's linux-next merge of the rcu tree got a conflict in:
> > 
> >   kernel/rcu/tree.c
> > 
> > between commits:
> > 
> >   806f04e9fd2c ("rcu: Allow for smp_call_function() running callbacks from idle")
> >   aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
> > 
> > from the tip tree and commit:
> > 
> >   c0601bb42994 ("rcu/tree: Clean up dynticks counter usage")
> >   3f3baaf3ac07 ("rcu/tree: Remove dynticks_nmi_nesting counter")
> > 
> > from the rcu tree.
> > 
> > I fixed it up (I punted and took some from the former and some from the
> > latter) 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.
> 
> I redid this and the resolution is below, but you should look at the
> final file when I do the release.

Given that the merge window might be opening in a couple days, my thought
is to defer these -rcu commits to my v5.9 pile, and then I resolve this
conflict in the -rcu tree when v5.8-rc1 comes out.  I just now adjusted
the -rcu tree's rcu/next branch accordingly.

Seem reasonable?

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree.c
> index c716eadc7617,78125749638f..1426b968eec1
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@@ -427,14 -385,8 +386,12 @@@ EXPORT_SYMBOL_GPL(rcu_momentary_dyntick
>    */
>   static int rcu_is_cpu_rrupt_from_idle(void)
>   {
> - 	long nesting;
> - 
>  -	/* Called only from within the scheduling-clock interrupt */
>  -	lockdep_assert_in_irq();
>  +	/*
>  +	 * Usually called from the tick; but also used from smp_function_call()
>  +	 * for expedited grace periods. This latter can result in running from
>  +	 * the idle task, instead of an actual IPI.
>  +	 */
>  +	lockdep_assert_irqs_disabled();
>   
>   	/* Check for counter underflows */
>   	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) < 0,
> @@@ -778,24 -718,6 +723,21 @@@ void rcu_irq_exit_preempt(void
>   			 "RCU in extended quiescent state!");
>   }
>   
>  +#ifdef CONFIG_PROVE_RCU
>  +/**
>  + * rcu_irq_exit_check_preempt - Validate that scheduling is possible
>  + */
>  +void rcu_irq_exit_check_preempt(void)
>  +{
>  +	lockdep_assert_irqs_disabled();
>  +
>  +	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) <= 0,
>  +			 "RCU dynticks_nesting counter underflow/zero!");
> - 	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nmi_nesting) !=
> - 			 DYNTICK_IRQ_NONIDLE,
> - 			 "Bad RCU  dynticks_nmi_nesting counter\n");
>  +	RCU_LOCKDEP_WARN(rcu_dynticks_curr_cpu_in_eqs(),
>  +			 "RCU in extended quiescent state!");
>  +}
>  +#endif /* #ifdef CONFIG_PROVE_RCU */
>  +
>   /*
>    * Wrapper for rcu_irq_exit() where interrupts are enabled.
>    *



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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-05-29  6:22 Stephen Rothwell
@ 2020-05-29  6:41 ` Stephen Rothwell
  2020-05-29 14:15   ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2020-05-29  6:41 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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

Hi all,

On Fri, 29 May 2020 16:22:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commits:
> 
>   806f04e9fd2c ("rcu: Allow for smp_call_function() running callbacks from idle")
>   aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
> 
> from the tip tree and commit:
> 
>   c0601bb42994 ("rcu/tree: Clean up dynticks counter usage")
>   3f3baaf3ac07 ("rcu/tree: Remove dynticks_nmi_nesting counter")
> 
> from the rcu tree.
> 
> I fixed it up (I punted and took some from the former and some from the
> latter) 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.

I redid this and the resolution is below, but you should look at the
final file when I do the release.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/rcu/tree.c
index c716eadc7617,78125749638f..1426b968eec1
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -427,14 -385,8 +386,12 @@@ EXPORT_SYMBOL_GPL(rcu_momentary_dyntick
   */
  static int rcu_is_cpu_rrupt_from_idle(void)
  {
- 	long nesting;
- 
 -	/* Called only from within the scheduling-clock interrupt */
 -	lockdep_assert_in_irq();
 +	/*
 +	 * Usually called from the tick; but also used from smp_function_call()
 +	 * for expedited grace periods. This latter can result in running from
 +	 * the idle task, instead of an actual IPI.
 +	 */
 +	lockdep_assert_irqs_disabled();
  
  	/* Check for counter underflows */
  	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) < 0,
@@@ -778,24 -718,6 +723,21 @@@ void rcu_irq_exit_preempt(void
  			 "RCU in extended quiescent state!");
  }
  
 +#ifdef CONFIG_PROVE_RCU
 +/**
 + * rcu_irq_exit_check_preempt - Validate that scheduling is possible
 + */
 +void rcu_irq_exit_check_preempt(void)
 +{
 +	lockdep_assert_irqs_disabled();
 +
 +	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) <= 0,
 +			 "RCU dynticks_nesting counter underflow/zero!");
- 	RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nmi_nesting) !=
- 			 DYNTICK_IRQ_NONIDLE,
- 			 "Bad RCU  dynticks_nmi_nesting counter\n");
 +	RCU_LOCKDEP_WARN(rcu_dynticks_curr_cpu_in_eqs(),
 +			 "RCU in extended quiescent state!");
 +}
 +#endif /* #ifdef CONFIG_PROVE_RCU */
 +
  /*
   * Wrapper for rcu_irq_exit() where interrupts are enabled.
   *

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-05-29  6:22 Stephen Rothwell
  2020-05-29  6:41 ` Stephen Rothwell
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2020-05-29  6:22 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

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

Hi all,

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

  kernel/rcu/tree.c

between commits:

  806f04e9fd2c ("rcu: Allow for smp_call_function() running callbacks from idle")
  aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")

from the tip tree and commit:

  3f3baaf3ac07 ("rcu/tree: Remove dynticks_nmi_nesting counter")
  c0601bb42994 ("rcu/tree: Clean up dynticks counter usage")
  3f3baaf3ac07 ("rcu/tree: Remove dynticks_nmi_nesting counter")

from the rcu tree.

I fixed it up (I punted and took some from the former and some from the
latter) 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] 71+ messages in thread

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-03-25  3:18 ` Paul E. McKenney
@ 2020-03-25 21:31   ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2020-03-25 21:31 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

On Tue, Mar 24, 2020 at 08:18:09PM -0700, Paul E. McKenney wrote:
> On Wed, Mar 25, 2020 at 02:08:45PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the rcu tree got conflicts in:
> > 
> >   lib/Kconfig.kcsan
> >   kernel/kcsan/report.c
> >   kernel/kcsan/kcsan.h
> >   kernel/kcsan/debugfs.c
> >   kernel/kcsan/core.c
> >   kernel/kcsan/atomic.h
> >   include/linux/kcsan-checks.h
> > 
> > between a series of commits from the tip tree and the same series of
> > patches (but different commits) in the rcu tre (followed by some more
> > changes in the rcu tree).
> > 
> > I fixed it up (I just used the rcu tree versions of these files) 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.
> > 
> > Please clean up the rcu tree WRT the tip tree.
> 
> Will do, and apologies for the hassle!

And done.  The rcu/next branch should now be fully compatible with
tip/master.

							Thanx, Paul

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2020-03-25  3:08 Stephen Rothwell
@ 2020-03-25  3:18 ` Paul E. McKenney
  2020-03-25 21:31   ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2020-03-25  3:18 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Mar 25, 2020 at 02:08:45PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got conflicts in:
> 
>   lib/Kconfig.kcsan
>   kernel/kcsan/report.c
>   kernel/kcsan/kcsan.h
>   kernel/kcsan/debugfs.c
>   kernel/kcsan/core.c
>   kernel/kcsan/atomic.h
>   include/linux/kcsan-checks.h
> 
> between a series of commits from the tip tree and the same series of
> patches (but different commits) in the rcu tre (followed by some more
> changes in the rcu tree).
> 
> I fixed it up (I just used the rcu tree versions of these files) 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.
> 
> Please clean up the rcu tree WRT the tip tree.

Will do, and apologies for the hassle!

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2020-03-25  3:08 Stephen Rothwell
  2020-03-25  3:18 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2020-03-25  3:08 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  lib/Kconfig.kcsan
  kernel/kcsan/report.c
  kernel/kcsan/kcsan.h
  kernel/kcsan/debugfs.c
  kernel/kcsan/core.c
  kernel/kcsan/atomic.h
  include/linux/kcsan-checks.h

between a series of commits from the tip tree and the same series of
patches (but different commits) in the rcu tre (followed by some more
changes in the rcu tree).

I fixed it up (I just used the rcu tree versions of these files) 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.

Please clean up the rcu tree WRT the tip tree.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2019-12-19  8:41     ` Peter Zijlstra
@ 2019-12-19 13:38       ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2019-12-19 13:38 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Dec 19, 2019 at 09:41:55AM +0100, Peter Zijlstra wrote:
> On Wed, Dec 18, 2019 at 05:31:51PM -0800, Paul E. McKenney wrote:
> > On Wed, Dec 18, 2019 at 05:27:26PM -0800, Paul E. McKenney wrote:
> > > On Thu, Dec 19, 2019 at 11:50:35AM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > Today's linux-next merge of the rcu tree got a conflict in:
> > > > 
> > > >   kernel/cpu.c
> > > > 
> > > > between commit:
> > > > 
> > > >   45178ac0cea8 ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > > > 
> > > > from the tip tree and commit:
> > > > 
> > > >   d62c673f4cfc ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > > > 
> > > > from the rcu 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.
> > > 
> > > I will pull this one out of the set that I mark for -next.  That way
> > > I can test and you can avoid at least this one conflict.  ;-)
> > 
> > Heh.  And the reason that it conflicts is that I fixed at least one
> > spelling error...  ;-)
> > 
> > Still, the one in tip is the official one, so I will proceed as planned.
> 
> Argh, my bad. I'd forgotten you'd already queued it, and I was holding
> onto it to make sure it didn't get lost. Now we haz it twice.

Better than losing the patch!  ;-)

							Thanx, Paul

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2019-12-19  1:31   ` Paul E. McKenney
@ 2019-12-19  8:41     ` Peter Zijlstra
  2019-12-19 13:38       ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Peter Zijlstra @ 2019-12-19  8:41 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Dec 18, 2019 at 05:31:51PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 18, 2019 at 05:27:26PM -0800, Paul E. McKenney wrote:
> > On Thu, Dec 19, 2019 at 11:50:35AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the rcu tree got a conflict in:
> > > 
> > >   kernel/cpu.c
> > > 
> > > between commit:
> > > 
> > >   45178ac0cea8 ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > > 
> > > from the tip tree and commit:
> > > 
> > >   d62c673f4cfc ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > > 
> > > from the rcu 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.
> > 
> > I will pull this one out of the set that I mark for -next.  That way
> > I can test and you can avoid at least this one conflict.  ;-)
> 
> Heh.  And the reason that it conflicts is that I fixed at least one
> spelling error...  ;-)
> 
> Still, the one in tip is the official one, so I will proceed as planned.

Argh, my bad. I'd forgotten you'd already queued it, and I was holding
onto it to make sure it didn't get lost. Now we haz it twice.

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2019-12-19  1:27 ` Paul E. McKenney
@ 2019-12-19  1:31   ` Paul E. McKenney
  2019-12-19  8:41     ` Peter Zijlstra
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2019-12-19  1:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Dec 18, 2019 at 05:27:26PM -0800, Paul E. McKenney wrote:
> On Thu, Dec 19, 2019 at 11:50:35AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the rcu tree got a conflict in:
> > 
> >   kernel/cpu.c
> > 
> > between commit:
> > 
> >   45178ac0cea8 ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > 
> > from the tip tree and commit:
> > 
> >   d62c673f4cfc ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> > 
> > from the rcu 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.
> 
> I will pull this one out of the set that I mark for -next.  That way
> I can test and you can avoid at least this one conflict.  ;-)

Heh.  And the reason that it conflicts is that I fixed at least one
spelling error...  ;-)

Still, the one in tip is the official one, so I will proceed as planned.

							Thanx, Paul

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2019-12-19  0:50 Stephen Rothwell
@ 2019-12-19  1:27 ` Paul E. McKenney
  2019-12-19  1:31   ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2019-12-19  1:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Dec 19, 2019 at 11:50:35AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/cpu.c
> 
> between commit:
> 
>   45178ac0cea8 ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> 
> from the tip tree and commit:
> 
>   d62c673f4cfc ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")
> 
> from the rcu 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.

I will pull this one out of the set that I mark for -next.  That way
I can test and you can avoid at least this one conflict.  ;-)

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2019-12-19  0:50 Stephen Rothwell
  2019-12-19  1:27 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2019-12-19  0:50 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  kernel/cpu.c

between commit:

  45178ac0cea8 ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")

from the tip tree and commit:

  d62c673f4cfc ("cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order")

from the rcu 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] 71+ messages in thread

* linux-next: manual merge of the rcu tree with the tip tree
@ 2019-12-16 23:37 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2019-12-16 23:37 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Marco Elver

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

Hi all,

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

  kernel/kcsan/core.c
  kernel/kcsan/encoding.h

between commit:

  5cbaefe9743b ("kcsan: Improve various small stylistic details")

from the tip tree and commit:

  b524b53678c6 ("kcsan: Prefer __always_inline for fast-path")

from the rcu 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/kcsan/core.c
index 3314fc29e236,69870645b631..000000000000
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@@ -78,10 -78,8 +78,10 @@@ static atomic_long_t watchpoints[CONFIG
   */
  static DEFINE_PER_CPU(long, kcsan_skip);
  
- static inline atomic_long_t *find_watchpoint(unsigned long addr,
- 					     size_t size,
- 					     bool expect_write,
- 					     long *encoded_watchpoint)
 -static __always_inline atomic_long_t *
 -find_watchpoint(unsigned long addr, size_t size, bool expect_write, long *encoded_watchpoint)
++static __always_inline atomic_long_t *find_watchpoint(unsigned long addr,
++						      size_t size,
++						      bool expect_write,
++						      long *encoded_watchpoint)
  {
  	const int slot = watchpoint_slot(addr);
  	const unsigned long addr_masked = addr & WATCHPOINT_ADDR_MASK;
@@@ -146,10 -149,11 +146,10 @@@ insert_watchpoint(unsigned long addr, s
   *	2. the thread that set up the watchpoint already removed it;
   *	3. the watchpoint was removed and then re-used.
   */
- static inline bool
+ static __always_inline bool
  try_consume_watchpoint(atomic_long_t *watchpoint, long encoded_watchpoint)
  {
 -	return atomic_long_try_cmpxchg_relaxed(watchpoint, &encoded_watchpoint,
 -					       CONSUMED_WATCHPOINT);
 +	return atomic_long_try_cmpxchg_relaxed(watchpoint, &encoded_watchpoint, CONSUMED_WATCHPOINT);
  }
  
  /*
@@@ -157,13 -161,14 +157,13 @@@
   */
  static inline bool remove_watchpoint(atomic_long_t *watchpoint)
  {
 -	return atomic_long_xchg_relaxed(watchpoint, INVALID_WATCHPOINT) !=
 -	       CONSUMED_WATCHPOINT;
 +	return atomic_long_xchg_relaxed(watchpoint, INVALID_WATCHPOINT) != CONSUMED_WATCHPOINT;
  }
  
- static inline struct kcsan_ctx *get_ctx(void)
+ static __always_inline struct kcsan_ctx *get_ctx(void)
  {
  	/*
 -	 * In interrupt, use raw_cpu_ptr to avoid unnecessary checks, that would
 +	 * In interrupts, use raw_cpu_ptr to avoid unnecessary checks, that would
  	 * also result in calls that generate warnings in uaccess regions.
  	 */
  	return in_task() ? &current->kcsan_ctx : raw_cpu_ptr(&kcsan_cpu_ctx);
diff --cc kernel/kcsan/encoding.h
index b63890e86449,e527e83ce825..000000000000
--- a/kernel/kcsan/encoding.h
+++ b/kernel/kcsan/encoding.h
@@@ -59,10 -58,8 +59,10 @@@ encode_watchpoint(unsigned long addr, s
  		      (addr & WATCHPOINT_ADDR_MASK));
  }
  
- static inline bool decode_watchpoint(long watchpoint,
- 				     unsigned long *addr_masked,
- 				     size_t *size,
- 				     bool *is_write)
 -static __always_inline bool
 -decode_watchpoint(long watchpoint, unsigned long *addr_masked, size_t *size, bool *is_write)
++static __always_inline bool decode_watchpoint(long watchpoint,
++					      unsigned long *addr_masked,
++					      size_t *size,
++					      bool *is_write)
  {
  	if (watchpoint == INVALID_WATCHPOINT ||
  	    watchpoint == CONSUMED_WATCHPOINT)

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2018-06-22  2:27 Stephen Rothwell
@ 2018-06-26 19:33 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2018-06-26 19:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Jun 22, 2018 at 12:27:17PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree_plugin.h
> 
> between commit:
> 
>   b3dae109fa89 ("sched/swait: Rename to exclusive")
> 
> from the tip tree and commit:
> 
>   57ada0a7f942 ("rcu: Convert grace-period requests to ->gp_seq")
> 
> from the rcu 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 good to me, and thank you!

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree_plugin.h
> index ad53d133f709,2cc9bf0d363a..000000000000
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@@ -2082,9 -2159,9 +2159,9 @@@ static void rcu_nocb_wait_gp(struct rcu
>   	 */
>   	trace_rcu_this_gp(rnp, rdp, c, TPS("StartWait"));
>   	for (;;) {
>  -		swait_event_interruptible(
>  +		swait_event_interruptible_exclusive(
> - 			rnp->nocb_gp_wq[c & 0x1],
> - 			(d = ULONG_CMP_GE(READ_ONCE(rnp->completed), c)));
> + 			rnp->nocb_gp_wq[rcu_seq_ctr(c) & 0x1],
> + 			(d = rcu_seq_done(&rnp->gp_seq, c)));
>   		if (likely(d))
>   			break;
>   		WARN_ON(signal_pending(current));

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2018-06-22  2:27 Stephen Rothwell
  2018-06-26 19:33 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2018-06-22  2:27 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi all,

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

  kernel/rcu/tree_plugin.h

between commit:

  b3dae109fa89 ("sched/swait: Rename to exclusive")

from the tip tree and commit:

  57ada0a7f942 ("rcu: Convert grace-period requests to ->gp_seq")

from the rcu 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/rcu/tree_plugin.h
index ad53d133f709,2cc9bf0d363a..000000000000
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@@ -2082,9 -2159,9 +2159,9 @@@ static void rcu_nocb_wait_gp(struct rcu
  	 */
  	trace_rcu_this_gp(rnp, rdp, c, TPS("StartWait"));
  	for (;;) {
 -		swait_event_interruptible(
 +		swait_event_interruptible_exclusive(
- 			rnp->nocb_gp_wq[c & 0x1],
- 			(d = ULONG_CMP_GE(READ_ONCE(rnp->completed), c)));
+ 			rnp->nocb_gp_wq[rcu_seq_ctr(c) & 0x1],
+ 			(d = rcu_seq_done(&rnp->gp_seq, c)));
  		if (likely(d))
  			break;
  		WARN_ON(signal_pending(current));

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2017-11-10  2:14 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2017-11-10  2:14 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Frederic Weisbecker

Hi Paul,

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

  kernel/rcu/tree.c

between commit:

  b04db8e19fc2 ("rcu: Use lockdep to assert IRQs are disabled/enabled")

from the tip tree and various commits from the rcu 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/rcu/tree.c
index f9c0ca2ccf0c,f1e3b6ebc978..000000000000
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -771,21 -760,20 +760,20 @@@ static void rcu_eqs_enter(bool user
  {
  	struct rcu_state *rsp;
  	struct rcu_data *rdp;
- 	struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ 	struct rcu_dynticks *rdtp;
  
- 	lockdep_assert_irqs_disabled();
- 	trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0);
- 	if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- 	    !user && !is_idle_task(current)) {
- 		struct task_struct *idle __maybe_unused =
- 			idle_task(smp_processor_id());
- 
- 		trace_rcu_dyntick(TPS("Error on entry: not idle task"), rdtp->dynticks_nesting, 0);
- 		rcu_ftrace_dump(DUMP_ORIG);
- 		WARN_ONCE(1, "Current pid: %d comm: %s / Idle pid: %d comm: %s",
- 			  current->pid, current->comm,
- 			  idle->pid, idle->comm); /* must be idle task! */
+ 	rdtp = this_cpu_ptr(&rcu_dynticks);
+ 	WRITE_ONCE(rdtp->dynticks_nmi_nesting, 0);
+ 	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
+ 		     rdtp->dynticks_nesting == 0);
+ 	if (rdtp->dynticks_nesting != 1) {
+ 		rdtp->dynticks_nesting--;
+ 		return;
  	}
+ 
 -	RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_eqs_enter() invoked with irqs enabled!!!");
++	lockdep_assert_irqs_disabled();
+ 	trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
+ 	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !user && !is_idle_task(current));
  	for_each_rcu_flavor(rsp) {
  		rdp = this_cpu_ptr(rsp->rda);
  		do_nocb_deferred_wakeup(rdp);
@@@ -887,23 -881,15 +881,15 @@@ void rcu_nmi_exit(void
   */
  void rcu_irq_exit(void)
  {
- 	struct rcu_dynticks *rdtp;
+ 	struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
  
 -	RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs enabled!!!");
 +	lockdep_assert_irqs_disabled();
- 	rdtp = this_cpu_ptr(&rcu_dynticks);
- 
- 	/* Page faults can happen in NMI handlers, so check... */
- 	if (rdtp->dynticks_nmi_nesting)
- 		return;
  
- 	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- 		     rdtp->dynticks_nesting < 1);
- 	if (rdtp->dynticks_nesting <= 1) {
- 		rcu_eqs_enter_common(true);
- 	} else {
- 		trace_rcu_dyntick(TPS("--="), rdtp->dynticks_nesting, rdtp->dynticks_nesting - 1);
- 		rdtp->dynticks_nesting--;
- 	}
+ 	if (rdtp->dynticks_nmi_nesting == 1)
+ 		rcu_prepare_for_idle();
+ 	rcu_nmi_exit();
+ 	if (rdtp->dynticks_nmi_nesting == 0)
+ 		rcu_dynticks_task_enter();
  }
  
  /*
@@@ -957,9 -918,9 +918,9 @@@ void rcu_irq_exit_irqson(void
  static void rcu_eqs_exit(bool user)
  {
  	struct rcu_dynticks *rdtp;
- 	long long oldval;
+ 	long oldval;
  
 -	RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_eqs_exit() invoked with irqs enabled!!!");
 +	lockdep_assert_irqs_disabled();
  	rdtp = this_cpu_ptr(&rcu_dynticks);
  	oldval = rdtp->dynticks_nesting;
  	WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && oldval < 0);
@@@ -1122,26 -1037,28 +1037,28 @@@ void rcu_irq_enter(void
  {
  	struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
  
- 	/*
- 	 * Check for ->dynticks_nmi_nesting underflow and bad ->dynticks.
- 	 * (We are exiting an NMI handler, so RCU better be paying attention
- 	 * to us!)
- 	 */
- 	WARN_ON_ONCE(rdtp->dynticks_nmi_nesting <= 0);
- 	WARN_ON_ONCE(rcu_dynticks_curr_cpu_in_eqs());
 -	RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_enter() invoked with irqs enabled!!!");
++	lockdep_assert_irqs_disabled();
  
- 	/*
- 	 * If the nesting level is not 1, the CPU wasn't RCU-idle, so
- 	 * leave it in non-RCU-idle state.
- 	 */
- 	if (rdtp->dynticks_nmi_nesting != 1) {
- 		rdtp->dynticks_nmi_nesting -= 2;
- 		return;
- 	}
+ 	if (rdtp->dynticks_nmi_nesting == 0)
+ 		rcu_dynticks_task_exit();
+ 	rcu_nmi_enter();
+ 	if (rdtp->dynticks_nmi_nesting == 1)
+ 		rcu_cleanup_after_idle();
+ }
  
- 	/* This NMI interrupted an RCU-idle CPU, restore RCU-idleness. */
- 	rdtp->dynticks_nmi_nesting = 0;
- 	rcu_dynticks_eqs_enter();
+ /*
+  * Wrapper for rcu_irq_enter() where interrupts are enabled.
+  *
+  * If you add or remove a call to rcu_irq_enter_irqson(), be sure to test
+  * with CONFIG_RCU_EQS_DEBUG=y.
+  */
+ void rcu_irq_enter_irqson(void)
+ {
+ 	unsigned long flags;
+ 
+ 	local_irq_save(flags);
+ 	rcu_irq_enter();
+ 	local_irq_restore(flags);
  }
  
  /**

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2017-08-22  4:13 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2017-08-22  4:13 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Mathieu Desnoyers, Andy Lutomirski

Hi all,

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

  arch/x86/mm/tlb.c

between commit:

  94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")

from the tip tree and commit:

  3ed668659e95 ("membarrier: Document scheduler barrier requirements")

from the rcu tree.

I am pretty sure I have reported this before ... but the latter commit
has been rebased.

I fixed it up (I again just dropped the additional commit in
switch_mm_irqs_off()) 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] 71+ messages in thread

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 14:15           ` Andy Lutomirski
  2017-08-01 15:40             ` Mathieu Desnoyers
@ 2017-08-01 21:36             ` Paul E. McKenney
  1 sibling, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2017-08-01 21:36 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Mathieu Desnoyers, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, linux-kernel

On Tue, Aug 01, 2017 at 07:15:40AM -0700, Andy Lutomirski wrote:
> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > /*
> >  * The full memory barrier implied by mm_cpumask update operations
> >  * is required by the membarrier system call.
> >  */
> >
> > What we want to order here is:
> >
> > prev userspace memory accesses
> > schedule
> >   <full mb> (it's already there) [A]
> >   update to rq->curr changing the rq->curr->mm value
> >   <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]
> 
> If I understand this right, the issue with relying on CR3 writes is
> that the target CPU could switch to a kernel thread and back to the
> same user mm white the membarrier caller is reading its mm, right?

The thing that got my attention was your patch removing the load_cr3().
Ah, looking closer, it appears that you have not eliminated the CR3
load, but just renamed it to write_cr3().  So if there is always still
a CR3 load, you are right, I should be able to simply move the comment.
Or let you insert the comment into your patch?

So there is still always a CR3 load, correct?  (Hey, I thought that
maybe x86 was moving to ASIDs or some such.)

							Thanx, Paul

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01  4:25       ` Mathieu Desnoyers
@ 2017-08-01 16:31         ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2017-08-01 16:31 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel,
	Andy Lutomirski

On Tue, Aug 01, 2017 at 04:25:56AM +0000, Mathieu Desnoyers wrote:
> ----- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:
> 
> > On Tue, Aug 01, 2017 at 12:04:05AM +0000, Mathieu Desnoyers wrote:
> >> ----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com
> >> wrote:
> >> 
> >> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
> >> >> Hi Paul,
> >> >> 
> >> >> Today's linux-next merge of the rcu tree got a conflict in:
> >> >> 
> >> >>   arch/x86/mm/tlb.c
> >> >> 
> >> >> between commit:
> >> >> 
> >> >>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
> >> >> 
> >> >> from the tip tree and commit:
> >> >> 
> >> >>   d7713e8f8b23 ("membarrier: Expedited private command")
> >> >> 
> >> >> from the rcu tree.
> >> >> 
> >> >> I fixed it up (the former removed the comment and the load_cr3(), so I
> >> >> just dropped the commend change in the latter) 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.
> >> > 
> >> > Thank you, Stephen!
> >> > 
> >> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
> >> > simply result in relying on the ordering provided by the atomic ops
> >> > in switch_mm() for mm_cpumask(), so that only the commit log and the
> >> > comment need changing.
> >> > 
> >> > Please let me know if I am missing something here.
> >> 
> >> I think you are right. Both load_cr3() and mm_cpumask update operations
> >> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
> >> matter of adapting the comment to the new reality.
> > 
> > Like this?
> 
> The updated comment in the commit message looks good, but I would be
> tempted to add a comment in x86 switch_mm_irqs_off() stating the
> following requirement just before the line invoking cpumask_set_cpu():
> 
> /*
>  * The full memory barrier implied by mm_cpumask update operations
>  * is required by the membarrier system call.
>  */

This looks good to me, but I will give the discussion another day or
so to settle out.  ;-)

							Thanx, Paul

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 14:15           ` Andy Lutomirski
@ 2017-08-01 15:40             ` Mathieu Desnoyers
  2017-08-01 21:36             ` Paul E. McKenney
  1 sibling, 0 replies; 71+ messages in thread
From: Mathieu Desnoyers @ 2017-08-01 15:40 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul E. McKenney, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux-Next Mailing List,
	linux-kernel

----- On Aug 1, 2017, at 10:15 AM, Andy Lutomirski luto@kernel.org wrote:

> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>> /*
>>  * The full memory barrier implied by mm_cpumask update operations
>>  * is required by the membarrier system call.
>>  */
>>
>> What we want to order here is:
>>
>> prev userspace memory accesses
>> schedule
>>   <full mb> (it's already there) [A]
>>   update to rq->curr changing the rq->curr->mm value
>>   <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]
> 
> If I understand this right, the issue with relying on CR3 writes is
> that the target CPU could switch to a kernel thread and back to the
> same user mm white the membarrier caller is reading its mm, right?

The current implementation of context_switch() does:

        mm = next->mm;
        oldmm = prev->active_mm;

        if (!mm)
                next->active_mm = oldmm;

        if (!prev->mm) {
                prev->active_mm = NULL;
                rq->prev_mm = oldmm;
        }

so basically the only way to have a non-null rq->prev_mm when we
reach finish_task_switch() is to have a non-null prev->active_mm
in context_switch (kernel thread).

finish_task_switch() has:

struct mm_struct *mm = rq->prev_mm;
[...]
if (mm)
        mmdrop(mm);

which issues a full memory barrier through atomic_dec_and_test(). This
happens to take care of this kthread->uthread scenario. I think it would
be important to document though.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 14:15           ` Peter Zijlstra
@ 2017-08-01 14:17             ` Andy Lutomirski
  0 siblings, 0 replies; 71+ messages in thread
From: Andy Lutomirski @ 2017-08-01 14:17 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Paul E. McKenney, Mathieu Desnoyers,
	Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, linux-kernel

On Tue, Aug 1, 2017 at 7:15 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Aug 01, 2017 at 03:58:49PM +0200, Peter Zijlstra wrote:
>> On Tue, Aug 01, 2017 at 06:43:14AM -0700, Andy Lutomirski wrote:
>> > Anyway, can you document whatever property you require with a comment
>> > in switch_mm() or wherever you're finding that property so that future
>> > arch changes don't break it?
>>
>> We need _a_ smp_mb after rq->curr store. x86 has plenty.
>
> That is, we need it when we change to a different !0 mm. And we have the
> mm_cpumask() atomics at the very least, even if loading a new CR3 would
> not be serializing.

I'm 99.5% sure that loading a new CR3 is always serializing even if it
doesn't flush the TLB.

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 13:58         ` Peter Zijlstra
@ 2017-08-01 14:15           ` Peter Zijlstra
  2017-08-01 14:17             ` Andy Lutomirski
  0 siblings, 1 reply; 71+ messages in thread
From: Peter Zijlstra @ 2017-08-01 14:15 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul E. McKenney, Mathieu Desnoyers, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, linux-kernel

On Tue, Aug 01, 2017 at 03:58:49PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 01, 2017 at 06:43:14AM -0700, Andy Lutomirski wrote:
> > Anyway, can you document whatever property you require with a comment
> > in switch_mm() or wherever you're finding that property so that future
> > arch changes don't break it?
> 
> We need _a_ smp_mb after rq->curr store. x86 has plenty.

That is, we need it when we change to a different !0 mm. And we have the
mm_cpumask() atomics at the very least, even if loading a new CR3 would
not be serializing.

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 14:02         ` Mathieu Desnoyers
@ 2017-08-01 14:15           ` Andy Lutomirski
  2017-08-01 15:40             ` Mathieu Desnoyers
  2017-08-01 21:36             ` Paul E. McKenney
  0 siblings, 2 replies; 71+ messages in thread
From: Andy Lutomirski @ 2017-08-01 14:15 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Andy Lutomirski, Paul E. McKenney, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, linux-kernel

On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> /*
>  * The full memory barrier implied by mm_cpumask update operations
>  * is required by the membarrier system call.
>  */
>
> What we want to order here is:
>
> prev userspace memory accesses
> schedule
>   <full mb> (it's already there) [A]
>   update to rq->curr changing the rq->curr->mm value
>   <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]

If I understand this right, the issue with relying on CR3 writes is
that the target CPU could switch to a kernel thread and back to the
same user mm white the membarrier caller is reading its mm, right?

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 13:43       ` Andy Lutomirski
  2017-08-01 13:58         ` Peter Zijlstra
@ 2017-08-01 14:02         ` Mathieu Desnoyers
  2017-08-01 14:15           ` Andy Lutomirski
  1 sibling, 1 reply; 71+ messages in thread
From: Mathieu Desnoyers @ 2017-08-01 14:02 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul E. McKenney, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Linux-Next Mailing List,
	linux-kernel

----- On Aug 1, 2017, at 9:43 AM, Andy Lutomirski luto@kernel.org wrote:

> On Mon, Jul 31, 2017 at 9:03 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>> On Tue, Aug 01, 2017 at 12:04:05AM +0000, Mathieu Desnoyers wrote:
>>> ----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com
>>> wrote:
>>>
> 
>>                                                         Thanx, Paul
>>
>> ------------------------------------------------------------------------
>>
>> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
>> Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> Date:   Fri Jul 28 16:40:40 2017 -0400
>>
>>     membarrier: Expedited private command
>>
>>     Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>>     from all runqueues for which current thread's mm is the same as the
>>     thread calling sys_membarrier. It executes faster than the non-expedited
>>     variant (no blocking). It also works on NOHZ_FULL configurations.
>>
>>     Scheduler-wise, it requires a memory barrier before and after context
>>     switching between processes (which have different mm). The memory
>>     barrier before context switch is already present. For the barrier after
>>     context switch:
>>
>>     * Our TSO archs can do RELEASE without being a full barrier. Look at
>>       x86 spin_unlock() being a regular STORE for example.  But for those
>>       archs, all atomics imply smp_mb and all of them have atomic ops in
>>       switch_mm() for mm_cpumask().
> 
> I think that, on x86, context switches, even without mm changes, must
> at least flush the store buffer (maybe SFENCE is okay) to avoid
> visible inconsistency due to store-buffer forwarding.
> 
> Anyway, can you document whatever property you require with a comment
> in switch_mm() or wherever you're finding that property so that future
> arch changes don't break it?

As I asked to Paul in my reply to his proposed manual merge,
we should indeed have a comment in switch_mm() stating something
like this just before the line invoking cpumask_set_cpu():

/*
 * The full memory barrier implied by mm_cpumask update operations
 * is required by the membarrier system call.
 */

What we want to order here is:

prev userspace memory accesses
schedule
  <full mb> (it's already there) [A]
  update to rq->curr changing the rq->curr->mm value
  <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]
next userspace memory accesses

wrt to:

userspace memory accesses
sys_membarrier
  <full mb> [C]
  iterate on each cpu's rq->curr, compare their "mm" to current->mm
    IPI each CPU that match
  <full mb> [D]
userspace memory accesses

[A] pairs with [D] and [B] pairs with [C].


> 
>> +static void membarrier_private_expedited(void)
>> +{
>> +       int cpu;
>> +       bool fallback = false;
>> +       cpumask_var_t tmpmask;
>> +
>> +       if (num_online_cpus() == 1)
>> +               return;
>> +
>> +       /*
>> +        * Matches memory barriers around rq->curr modification in
>> +        * scheduler.
>> +        */
>> +       smp_mb();       /* system call entry is not a mb. */
>> +
>> +       /*
>> +        * Expedited membarrier commands guarantee that they won't
>> +        * block, hence the GFP_NOWAIT allocation flag and fallback
>> +        * implementation.
>> +        */
>> +       if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) {
>> +               /* Fallback for OOM. */
>> +               fallback = true;
>> +       }
>> +
>> +       cpus_read_lock();
>> +       for_each_online_cpu(cpu) {
>> +               struct task_struct *p;
>> +
>> +               /*
>> +                * Skipping the current CPU is OK even through we can be
>> +                * migrated at any point. The current CPU, at the point
>> +                * where we read raw_smp_processor_id(), is ensured to
>> +                * be in program order with respect to the caller
>> +                * thread. Therefore, we can skip this CPU from the
>> +                * iteration.
>> +                */
>> +               if (cpu == raw_smp_processor_id())
>> +                       continue;
>> +               rcu_read_lock();
>> +               p = task_rcu_dereference(&cpu_rq(cpu)->curr);
>> +               if (p && p->mm == current->mm) {
> 
> I'm a bit surprised you're iterating all CPUs instead of just CPUs in
> mm_cpumask().

I see two reasons for this. The first is because architectures like
ARM64 don't even bother populating the mm_cpumask. The second reason
is because I don't think all architectures ensure that updates to
mm_cpumask imply full memory barriers. Therefore, we would need to revisit
each architecture switch_mm to ensure mm_cpumask bit set ops either imply
a full memory barrier, or are followed by an explicit one, if we
choose to use this bitmask as an optimization.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01 13:43       ` Andy Lutomirski
@ 2017-08-01 13:58         ` Peter Zijlstra
  2017-08-01 14:15           ` Peter Zijlstra
  2017-08-01 14:02         ` Mathieu Desnoyers
  1 sibling, 1 reply; 71+ messages in thread
From: Peter Zijlstra @ 2017-08-01 13:58 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul E. McKenney, Mathieu Desnoyers, Stephen Rothwell,
	Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Linux-Next Mailing List, linux-kernel

On Tue, Aug 01, 2017 at 06:43:14AM -0700, Andy Lutomirski wrote:
> Anyway, can you document whatever property you require with a comment
> in switch_mm() or wherever you're finding that property so that future
> arch changes don't break it?

We need _a_ smp_mb after rq->curr store. x86 has plenty.

> > +static void membarrier_private_expedited(void)
> > +{
> > +       int cpu;
> > +       bool fallback = false;
> > +       cpumask_var_t tmpmask;
> > +
> > +       if (num_online_cpus() == 1)
> > +               return;
> > +
> > +       /*
> > +        * Matches memory barriers around rq->curr modification in
> > +        * scheduler.
> > +        */
> > +       smp_mb();       /* system call entry is not a mb. */
> > +
> > +       /*
> > +        * Expedited membarrier commands guarantee that they won't
> > +        * block, hence the GFP_NOWAIT allocation flag and fallback
> > +        * implementation.
> > +        */
> > +       if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) {
> > +               /* Fallback for OOM. */
> > +               fallback = true;
> > +       }
> > +
> > +       cpus_read_lock();
> > +       for_each_online_cpu(cpu) {
> > +               struct task_struct *p;
> > +
> > +               /*
> > +                * Skipping the current CPU is OK even through we can be
> > +                * migrated at any point. The current CPU, at the point
> > +                * where we read raw_smp_processor_id(), is ensured to
> > +                * be in program order with respect to the caller
> > +                * thread. Therefore, we can skip this CPU from the
> > +                * iteration.
> > +                */
> > +               if (cpu == raw_smp_processor_id())
> > +                       continue;
> > +               rcu_read_lock();
> > +               p = task_rcu_dereference(&cpu_rq(cpu)->curr);
> > +               if (p && p->mm == current->mm) {
> 
> I'm a bit surprised you're iterating all CPUs instead of just CPUs in
> mm_cpumask().

Because ARM64 doesn't set any bits at all in there.

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01  4:03     ` Paul E. McKenney
  2017-08-01  4:25       ` Mathieu Desnoyers
@ 2017-08-01 13:43       ` Andy Lutomirski
  2017-08-01 13:58         ` Peter Zijlstra
  2017-08-01 14:02         ` Mathieu Desnoyers
  1 sibling, 2 replies; 71+ messages in thread
From: Andy Lutomirski @ 2017-08-01 13:43 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Mathieu Desnoyers, Stephen Rothwell, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, linux-kernel, Andy Lutomirski

On Mon, Jul 31, 2017 at 9:03 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Tue, Aug 01, 2017 at 12:04:05AM +0000, Mathieu Desnoyers wrote:
>> ----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:
>>

>                                                         Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Date:   Fri Jul 28 16:40:40 2017 -0400
>
>     membarrier: Expedited private command
>
>     Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>     from all runqueues for which current thread's mm is the same as the
>     thread calling sys_membarrier. It executes faster than the non-expedited
>     variant (no blocking). It also works on NOHZ_FULL configurations.
>
>     Scheduler-wise, it requires a memory barrier before and after context
>     switching between processes (which have different mm). The memory
>     barrier before context switch is already present. For the barrier after
>     context switch:
>
>     * Our TSO archs can do RELEASE without being a full barrier. Look at
>       x86 spin_unlock() being a regular STORE for example.  But for those
>       archs, all atomics imply smp_mb and all of them have atomic ops in
>       switch_mm() for mm_cpumask().

I think that, on x86, context switches, even without mm changes, must
at least flush the store buffer (maybe SFENCE is okay) to avoid
visible inconsistency due to store-buffer forwarding.

Anyway, can you document whatever property you require with a comment
in switch_mm() or wherever you're finding that property so that future
arch changes don't break it?

> +static void membarrier_private_expedited(void)
> +{
> +       int cpu;
> +       bool fallback = false;
> +       cpumask_var_t tmpmask;
> +
> +       if (num_online_cpus() == 1)
> +               return;
> +
> +       /*
> +        * Matches memory barriers around rq->curr modification in
> +        * scheduler.
> +        */
> +       smp_mb();       /* system call entry is not a mb. */
> +
> +       /*
> +        * Expedited membarrier commands guarantee that they won't
> +        * block, hence the GFP_NOWAIT allocation flag and fallback
> +        * implementation.
> +        */
> +       if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) {
> +               /* Fallback for OOM. */
> +               fallback = true;
> +       }
> +
> +       cpus_read_lock();
> +       for_each_online_cpu(cpu) {
> +               struct task_struct *p;
> +
> +               /*
> +                * Skipping the current CPU is OK even through we can be
> +                * migrated at any point. The current CPU, at the point
> +                * where we read raw_smp_processor_id(), is ensured to
> +                * be in program order with respect to the caller
> +                * thread. Therefore, we can skip this CPU from the
> +                * iteration.
> +                */
> +               if (cpu == raw_smp_processor_id())
> +                       continue;
> +               rcu_read_lock();
> +               p = task_rcu_dereference(&cpu_rq(cpu)->curr);
> +               if (p && p->mm == current->mm) {

I'm a bit surprised you're iterating all CPUs instead of just CPUs in
mm_cpumask().

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01  4:03     ` Paul E. McKenney
@ 2017-08-01  4:25       ` Mathieu Desnoyers
  2017-08-01 16:31         ` Paul E. McKenney
  2017-08-01 13:43       ` Andy Lutomirski
  1 sibling, 1 reply; 71+ messages in thread
From: Mathieu Desnoyers @ 2017-08-01  4:25 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel,
	Andy Lutomirski

----- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:

> On Tue, Aug 01, 2017 at 12:04:05AM +0000, Mathieu Desnoyers wrote:
>> ----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com
>> wrote:
>> 
>> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
>> >> Hi Paul,
>> >> 
>> >> Today's linux-next merge of the rcu tree got a conflict in:
>> >> 
>> >>   arch/x86/mm/tlb.c
>> >> 
>> >> between commit:
>> >> 
>> >>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
>> >> 
>> >> from the tip tree and commit:
>> >> 
>> >>   d7713e8f8b23 ("membarrier: Expedited private command")
>> >> 
>> >> from the rcu tree.
>> >> 
>> >> I fixed it up (the former removed the comment and the load_cr3(), so I
>> >> just dropped the commend change in the latter) 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.
>> > 
>> > Thank you, Stephen!
>> > 
>> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
>> > simply result in relying on the ordering provided by the atomic ops
>> > in switch_mm() for mm_cpumask(), so that only the commit log and the
>> > comment need changing.
>> > 
>> > Please let me know if I am missing something here.
>> 
>> I think you are right. Both load_cr3() and mm_cpumask update operations
>> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
>> matter of adapting the comment to the new reality.
> 
> Like this?

The updated comment in the commit message looks good, but I would be
tempted to add a comment in x86 switch_mm_irqs_off() stating the
following requirement just before the line invoking cpumask_set_cpu():

/*
 * The full memory barrier implied by mm_cpumask update operations
 * is required by the membarrier system call.
 */

Thanks,

Mathieu

> 
>							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Date:   Fri Jul 28 16:40:40 2017 -0400
> 
>    membarrier: Expedited private command
>    
>    Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>    from all runqueues for which current thread's mm is the same as the
>    thread calling sys_membarrier. It executes faster than the non-expedited
>    variant (no blocking). It also works on NOHZ_FULL configurations.
>    
>    Scheduler-wise, it requires a memory barrier before and after context
>    switching between processes (which have different mm). The memory
>    barrier before context switch is already present. For the barrier after
>    context switch:
>    
>    * Our TSO archs can do RELEASE without being a full barrier. Look at
>      x86 spin_unlock() being a regular STORE for example.  But for those
>      archs, all atomics imply smp_mb and all of them have atomic ops in
>      switch_mm() for mm_cpumask().
>    
>    * From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
>      the rest does indeed do smp_mb(), so there the spin_unlock() is a full
>      barrier and we're good.
>    
>    * ARM64 has a very heavy barrier in switch_to(), which suffices.
>    
>    * PPC just removed its barrier from switch_to(), but appears to be
>      talking about adding something to switch_mm(). So add a
>      smp_mb__after_unlock_lock() for now, until this is settled on the PPC
>      side.
>    
>    Changes since v3:
>    - Properly document the memory barriers provided by each architecture.
>    
>    Changes since v2:
>    - Address comments from Peter Zijlstra,
>    - Add smp_mb__after_unlock_lock() after finish_lock_switch() in
>      finish_task_switch() to add the memory barrier we need after storing
>      to rq->curr. This is much simpler than the previous approach relying
>      on atomic_dec_and_test() in mmdrop(), which actually added a memory
>      barrier in the common case of switching between userspace processes.
>    - Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
>      kernel, rather than having the whole membarrier system call returning
>      -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
>      Adapt the CMD_QUERY mask accordingly.
>    
>    Changes since v1:
>    - move membarrier code under kernel/sched/ because it uses the
>      scheduler runqueue,
>    - only add the barrier when we switch from a kernel thread. The case
>      where we switch from a user-space thread is already handled by
>      the atomic_dec_and_test() in mmdrop().
>    - add a comment to mmdrop() documenting the requirement on the implicit
>      memory barrier.
>    
>    CC: Peter Zijlstra <peterz@infradead.org>
>    CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    CC: Boqun Feng <boqun.feng@gmail.com>
>    CC: Andrew Hunter <ahh@google.com>
>    CC: Maged Michael <maged.michael@gmail.com>
>    CC: gromer@google.com
>    CC: Avi Kivity <avi@scylladb.com>
>    CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>    CC: Paul Mackerras <paulus@samba.org>
>    CC: Michael Ellerman <mpe@ellerman.id.au>
>    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>    Tested-by: Dave Watson <davejwatson@fb.com>
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f66488dfdbc9..3b035584272f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8621,7 +8621,7 @@ M:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> M:	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> L:	linux-kernel@vger.kernel.org
> S:	Supported
> -F:	kernel/membarrier.c
> +F:	kernel/sched/membarrier.c
> F:	include/uapi/linux/membarrier.h
> 
> MEMORY MANAGEMENT
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 659ae8094ed5..c8f7d98d8cb9 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -360,6 +360,8 @@ __notrace_funcgraph struct task_struct *__switch_to(struct
> task_struct *prev,
> 	/*
> 	 * Complete any pending TLB or cache maintenance on this CPU in case
> 	 * the thread migrates to a different CPU.
> +	 * This full barrier is also required by the membarrier system
> +	 * call.
> 	 */
> 	dsb(ish);
> 
> diff --git a/include/uapi/linux/membarrier.h b/include/uapi/linux/membarrier.h
> index e0b108bd2624..6d47b3249d8a 100644
> --- a/include/uapi/linux/membarrier.h
> +++ b/include/uapi/linux/membarrier.h
> @@ -40,14 +40,33 @@
>  *                          (non-running threads are de facto in such a
>  *                          state). This covers threads from all processes
>  *                          running on the system. This command returns 0.
> + * @MEMBARRIER_CMD_PRIVATE_EXPEDITED:
> + *                          Execute a memory barrier on each running
> + *                          thread belonging to the same process as the current
> + *                          thread. Upon return from system call, the
> + *                          caller thread is ensured that all its running
> + *                          threads siblings have passed through a state
> + *                          where all memory accesses to user-space
> + *                          addresses match program order between entry
> + *                          to and return from the system call
> + *                          (non-running threads are de facto in such a
> + *                          state). This only covers threads from the
> + *                          same processes as the caller thread. This
> + *                          command returns 0. The "expedited" commands
> + *                          complete faster than the non-expedited ones,
> + *                          they never block, but have the downside of
> + *                          causing extra overhead.
>  *
>  * Command to be passed to the membarrier system call. The commands need to
>  * be a single bit each, except for MEMBARRIER_CMD_QUERY which is assigned to
>  * the value 0.
>  */
> enum membarrier_cmd {
> -	MEMBARRIER_CMD_QUERY = 0,
> -	MEMBARRIER_CMD_SHARED = (1 << 0),
> +	MEMBARRIER_CMD_QUERY			= 0,
> +	MEMBARRIER_CMD_SHARED			= (1 << 0),
> +	/* reserved for MEMBARRIER_CMD_SHARED_EXPEDITED (1 << 1) */
> +	/* reserved for MEMBARRIER_CMD_PRIVATE (1 << 2) */
> +	MEMBARRIER_CMD_PRIVATE_EXPEDITED	= (1 << 3),
> };
> 
> #endif /* _UAPI_LINUX_MEMBARRIER_H */
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 4cb8e8b23c6e..9c323a6daa46 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -108,7 +108,6 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> obj-$(CONFIG_JUMP_LABEL) += jump_label.o
> obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
> obj-$(CONFIG_TORTURE_TEST) += torture.o
> -obj-$(CONFIG_MEMBARRIER) += membarrier.o
> 
> obj-$(CONFIG_HAS_IOMEM) += memremap.o
> 
> diff --git a/kernel/membarrier.c b/kernel/membarrier.c
> deleted file mode 100644
> index 9f9284f37f8d..000000000000
> --- a/kernel/membarrier.c
> +++ /dev/null
> @@ -1,70 +0,0 @@
> -/*
> - * Copyright (C) 2010, 2015 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> - *
> - * membarrier system call
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -#include <linux/syscalls.h>
> -#include <linux/membarrier.h>
> -#include <linux/tick.h>
> -
> -/*
> - * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> - * except MEMBARRIER_CMD_QUERY.
> - */
> -#define MEMBARRIER_CMD_BITMASK	(MEMBARRIER_CMD_SHARED)
> -
> -/**
> - * sys_membarrier - issue memory barriers on a set of threads
> - * @cmd:   Takes command values defined in enum membarrier_cmd.
> - * @flags: Currently needs to be 0. For future extensions.
> - *
> - * If this system call is not implemented, -ENOSYS is returned. If the
> - * command specified does not exist, or if the command argument is invalid,
> - * this system call returns -EINVAL. For a given command, with flags argument
> - * set to 0, this system call is guaranteed to always return the same value
> - * until reboot.
> - *
> - * All memory accesses performed in program order from each targeted thread
> - * is guaranteed to be ordered with respect to sys_membarrier(). If we use
> - * the semantic "barrier()" to represent a compiler barrier forcing memory
> - * accesses to be performed in program order across the barrier, and
> - * smp_mb() to represent explicit memory barriers forcing full memory
> - * ordering across the barrier, we have the following ordering table for
> - * each pair of barrier(), sys_membarrier() and smp_mb():
> - *
> - * The pair ordering is detailed as (O: ordered, X: not ordered):
> - *
> - *                        barrier()   smp_mb() sys_membarrier()
> - *        barrier()          X           X            O
> - *        smp_mb()           X           O            O
> - *        sys_membarrier()   O           O            O
> - */
> -SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> -{
> -	/* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
> -	if (tick_nohz_full_enabled())
> -		return -ENOSYS;
> -	if (unlikely(flags))
> -		return -EINVAL;
> -	switch (cmd) {
> -	case MEMBARRIER_CMD_QUERY:
> -		return MEMBARRIER_CMD_BITMASK;
> -	case MEMBARRIER_CMD_SHARED:
> -		if (num_online_cpus() > 1)
> -			synchronize_sched();
> -		return 0;
> -	default:
> -		return -EINVAL;
> -	}
> -}
> diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
> index 53f0164ed362..78f54932ea1d 100644
> --- a/kernel/sched/Makefile
> +++ b/kernel/sched/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_SCHED_DEBUG) += debug.o
> obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
> obj-$(CONFIG_CPU_FREQ) += cpufreq.o
> obj-$(CONFIG_CPU_FREQ_GOV_SCHEDUTIL) += cpufreq_schedutil.o
> +obj-$(CONFIG_MEMBARRIER) += membarrier.o
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index bfee6ea7db49..f77269c6c2f8 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2640,6 +2640,16 @@ static struct rq *finish_task_switch(struct task_struct
> *prev)
> 	prev_state = prev->state;
> 	vtime_task_switch(prev);
> 	perf_event_task_sched_in(prev, current);
> +	/*
> +	 * The membarrier system call requires a full memory barrier
> +	 * after storing to rq->curr, before going back to user-space.
> +	 *
> +	 * TODO: This smp_mb__after_unlock_lock can go away if PPC end
> +	 * up adding a full barrier to switch_mm(), or we should figure
> +	 * out if a smp_mb__after_unlock_lock is really the proper API
> +	 * to use.
> +	 */
> +	smp_mb__after_unlock_lock();
> 	finish_lock_switch(rq, prev);
> 	finish_arch_post_lock_switch();
> 
> @@ -3329,6 +3339,21 @@ static void __sched notrace __schedule(bool preempt)
> 	if (likely(prev != next)) {
> 		rq->nr_switches++;
> 		rq->curr = next;
> +		/*
> +		 * The membarrier system call requires each architecture
> +		 * to have a full memory barrier after updating
> +		 * rq->curr, before returning to user-space. For TSO
> +		 * (e.g. x86), the architecture must provide its own
> +		 * barrier in switch_mm(). For weakly ordered machines
> +		 * for which spin_unlock() acts as a full memory
> +		 * barrier, finish_lock_switch() in common code takes
> +		 * care of this barrier. For weakly ordered machines for
> +		 * which spin_unlock() acts as a RELEASE barrier (only
> +		 * arm64 and PowerPC), arm64 has a full barrier in
> +		 * switch_to(), and PowerPC has
> +		 * smp_mb__after_unlock_lock() before
> +		 * finish_lock_switch().
> +		 */
> 		++*switch_count;
> 
> 		trace_sched_switch(preempt, prev, next);
> diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
> new file mode 100644
> index 000000000000..a92fddc22747
> --- /dev/null
> +++ b/kernel/sched/membarrier.c
> @@ -0,0 +1,152 @@
> +/*
> + * Copyright (C) 2010-2017 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> + *
> + * membarrier system call
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/syscalls.h>
> +#include <linux/membarrier.h>
> +#include <linux/tick.h>
> +#include <linux/cpumask.h>
> +
> +#include "sched.h"	/* for cpu_rq(). */
> +
> +/*
> + * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> + * except MEMBARRIER_CMD_QUERY.
> + */
> +#define MEMBARRIER_CMD_BITMASK	\
> +	(MEMBARRIER_CMD_SHARED | MEMBARRIER_CMD_PRIVATE_EXPEDITED)
> +
> +static void ipi_mb(void *info)
> +{
> +	smp_mb();	/* IPIs should be serializing but paranoid. */
> +}
> +
> +static void membarrier_private_expedited(void)
> +{
> +	int cpu;
> +	bool fallback = false;
> +	cpumask_var_t tmpmask;
> +
> +	if (num_online_cpus() == 1)
> +		return;
> +
> +	/*
> +	 * Matches memory barriers around rq->curr modification in
> +	 * scheduler.
> +	 */
> +	smp_mb();	/* system call entry is not a mb. */
> +
> +	/*
> +	 * Expedited membarrier commands guarantee that they won't
> +	 * block, hence the GFP_NOWAIT allocation flag and fallback
> +	 * implementation.
> +	 */
> +	if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) {
> +		/* Fallback for OOM. */
> +		fallback = true;
> +	}
> +
> +	cpus_read_lock();
> +	for_each_online_cpu(cpu) {
> +		struct task_struct *p;
> +
> +		/*
> +		 * Skipping the current CPU is OK even through we can be
> +		 * migrated at any point. The current CPU, at the point
> +		 * where we read raw_smp_processor_id(), is ensured to
> +		 * be in program order with respect to the caller
> +		 * thread. Therefore, we can skip this CPU from the
> +		 * iteration.
> +		 */
> +		if (cpu == raw_smp_processor_id())
> +			continue;
> +		rcu_read_lock();
> +		p = task_rcu_dereference(&cpu_rq(cpu)->curr);
> +		if (p && p->mm == current->mm) {
> +			if (!fallback)
> +				__cpumask_set_cpu(cpu, tmpmask);
> +			else
> +				smp_call_function_single(cpu, ipi_mb, NULL, 1);
> +		}
> +		rcu_read_unlock();
> +	}
> +	if (!fallback) {
> +		smp_call_function_many(tmpmask, ipi_mb, NULL, 1);
> +		free_cpumask_var(tmpmask);
> +	}
> +	cpus_read_unlock();
> +
> +	/*
> +	 * Memory barrier on the caller thread _after_ we finished
> +	 * waiting for the last IPI. Matches memory barriers around
> +	 * rq->curr modification in scheduler.
> +	 */
> +	smp_mb();	/* exit from system call is not a mb */
> +}
> +
> +/**
> + * sys_membarrier - issue memory barriers on a set of threads
> + * @cmd:   Takes command values defined in enum membarrier_cmd.
> + * @flags: Currently needs to be 0. For future extensions.
> + *
> + * If this system call is not implemented, -ENOSYS is returned. If the
> + * command specified does not exist, not available on the running
> + * kernel, or if the command argument is invalid, this system call
> + * returns -EINVAL. For a given command, with flags argument set to 0,
> + * this system call is guaranteed to always return the same value until
> + * reboot.
> + *
> + * All memory accesses performed in program order from each targeted thread
> + * is guaranteed to be ordered with respect to sys_membarrier(). If we use
> + * the semantic "barrier()" to represent a compiler barrier forcing memory
> + * accesses to be performed in program order across the barrier, and
> + * smp_mb() to represent explicit memory barriers forcing full memory
> + * ordering across the barrier, we have the following ordering table for
> + * each pair of barrier(), sys_membarrier() and smp_mb():
> + *
> + * The pair ordering is detailed as (O: ordered, X: not ordered):
> + *
> + *                        barrier()   smp_mb() sys_membarrier()
> + *        barrier()          X           X            O
> + *        smp_mb()           X           O            O
> + *        sys_membarrier()   O           O            O
> + */
> +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> +{
> +	if (unlikely(flags))
> +		return -EINVAL;
> +	switch (cmd) {
> +	case MEMBARRIER_CMD_QUERY:
> +	{
> +		int cmd_mask = MEMBARRIER_CMD_BITMASK;
> +
> +		if (tick_nohz_full_enabled())
> +			cmd_mask &= ~MEMBARRIER_CMD_SHARED;
> +		return cmd_mask;
> +	}
> +	case MEMBARRIER_CMD_SHARED:
> +		/* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
> +		if (tick_nohz_full_enabled())
> +			return -EINVAL;
> +		if (num_online_cpus() > 1)
> +			synchronize_sched();
> +		return 0;
> +	case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
> +		membarrier_private_expedited();
> +		return 0;
> +	default:
> +		return -EINVAL;
> +	}
> +}

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-08-01  0:04   ` Mathieu Desnoyers
@ 2017-08-01  4:03     ` Paul E. McKenney
  2017-08-01  4:25       ` Mathieu Desnoyers
  2017-08-01 13:43       ` Andy Lutomirski
  0 siblings, 2 replies; 71+ messages in thread
From: Paul E. McKenney @ 2017-08-01  4:03 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel,
	Andy Lutomirski

On Tue, Aug 01, 2017 at 12:04:05AM +0000, Mathieu Desnoyers wrote:
> ----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:
> 
> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >> 
> >> Today's linux-next merge of the rcu tree got a conflict in:
> >> 
> >>   arch/x86/mm/tlb.c
> >> 
> >> between commit:
> >> 
> >>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
> >> 
> >> from the tip tree and commit:
> >> 
> >>   d7713e8f8b23 ("membarrier: Expedited private command")
> >> 
> >> from the rcu tree.
> >> 
> >> I fixed it up (the former removed the comment and the load_cr3(), so I
> >> just dropped the commend change in the latter) 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.
> > 
> > Thank you, Stephen!
> > 
> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
> > simply result in relying on the ordering provided by the atomic ops
> > in switch_mm() for mm_cpumask(), so that only the commit log and the
> > comment need changing.
> > 
> > Please let me know if I am missing something here.
> 
> I think you are right. Both load_cr3() and mm_cpumask update operations
> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
> matter of adapting the comment to the new reality.

Like this?

							Thanx, Paul

------------------------------------------------------------------------

commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Fri Jul 28 16:40:40 2017 -0400

    membarrier: Expedited private command
    
    Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
    from all runqueues for which current thread's mm is the same as the
    thread calling sys_membarrier. It executes faster than the non-expedited
    variant (no blocking). It also works on NOHZ_FULL configurations.
    
    Scheduler-wise, it requires a memory barrier before and after context
    switching between processes (which have different mm). The memory
    barrier before context switch is already present. For the barrier after
    context switch:
    
    * Our TSO archs can do RELEASE without being a full barrier. Look at
      x86 spin_unlock() being a regular STORE for example.  But for those
      archs, all atomics imply smp_mb and all of them have atomic ops in
      switch_mm() for mm_cpumask().
    
    * From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
      the rest does indeed do smp_mb(), so there the spin_unlock() is a full
      barrier and we're good.
    
    * ARM64 has a very heavy barrier in switch_to(), which suffices.
    
    * PPC just removed its barrier from switch_to(), but appears to be
      talking about adding something to switch_mm(). So add a
      smp_mb__after_unlock_lock() for now, until this is settled on the PPC
      side.
    
    Changes since v3:
    - Properly document the memory barriers provided by each architecture.
    
    Changes since v2:
    - Address comments from Peter Zijlstra,
    - Add smp_mb__after_unlock_lock() after finish_lock_switch() in
      finish_task_switch() to add the memory barrier we need after storing
      to rq->curr. This is much simpler than the previous approach relying
      on atomic_dec_and_test() in mmdrop(), which actually added a memory
      barrier in the common case of switching between userspace processes.
    - Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
      kernel, rather than having the whole membarrier system call returning
      -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
      Adapt the CMD_QUERY mask accordingly.
    
    Changes since v1:
    - move membarrier code under kernel/sched/ because it uses the
      scheduler runqueue,
    - only add the barrier when we switch from a kernel thread. The case
      where we switch from a user-space thread is already handled by
      the atomic_dec_and_test() in mmdrop().
    - add a comment to mmdrop() documenting the requirement on the implicit
      memory barrier.
    
    CC: Peter Zijlstra <peterz@infradead.org>
    CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    CC: Boqun Feng <boqun.feng@gmail.com>
    CC: Andrew Hunter <ahh@google.com>
    CC: Maged Michael <maged.michael@gmail.com>
    CC: gromer@google.com
    CC: Avi Kivity <avi@scylladb.com>
    CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    CC: Paul Mackerras <paulus@samba.org>
    CC: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Dave Watson <davejwatson@fb.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index f66488dfdbc9..3b035584272f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8621,7 +8621,7 @@ M:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
 M:	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
 L:	linux-kernel@vger.kernel.org
 S:	Supported
-F:	kernel/membarrier.c
+F:	kernel/sched/membarrier.c
 F:	include/uapi/linux/membarrier.h
 
 MEMORY MANAGEMENT
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 659ae8094ed5..c8f7d98d8cb9 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -360,6 +360,8 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
 	/*
 	 * Complete any pending TLB or cache maintenance on this CPU in case
 	 * the thread migrates to a different CPU.
+	 * This full barrier is also required by the membarrier system
+	 * call.
 	 */
 	dsb(ish);
 
diff --git a/include/uapi/linux/membarrier.h b/include/uapi/linux/membarrier.h
index e0b108bd2624..6d47b3249d8a 100644
--- a/include/uapi/linux/membarrier.h
+++ b/include/uapi/linux/membarrier.h
@@ -40,14 +40,33 @@
  *                          (non-running threads are de facto in such a
  *                          state). This covers threads from all processes
  *                          running on the system. This command returns 0.
+ * @MEMBARRIER_CMD_PRIVATE_EXPEDITED:
+ *                          Execute a memory barrier on each running
+ *                          thread belonging to the same process as the current
+ *                          thread. Upon return from system call, the
+ *                          caller thread is ensured that all its running
+ *                          threads siblings have passed through a state
+ *                          where all memory accesses to user-space
+ *                          addresses match program order between entry
+ *                          to and return from the system call
+ *                          (non-running threads are de facto in such a
+ *                          state). This only covers threads from the
+ *                          same processes as the caller thread. This
+ *                          command returns 0. The "expedited" commands
+ *                          complete faster than the non-expedited ones,
+ *                          they never block, but have the downside of
+ *                          causing extra overhead.
  *
  * Command to be passed to the membarrier system call. The commands need to
  * be a single bit each, except for MEMBARRIER_CMD_QUERY which is assigned to
  * the value 0.
  */
 enum membarrier_cmd {
-	MEMBARRIER_CMD_QUERY = 0,
-	MEMBARRIER_CMD_SHARED = (1 << 0),
+	MEMBARRIER_CMD_QUERY			= 0,
+	MEMBARRIER_CMD_SHARED			= (1 << 0),
+	/* reserved for MEMBARRIER_CMD_SHARED_EXPEDITED (1 << 1) */
+	/* reserved for MEMBARRIER_CMD_PRIVATE (1 << 2) */
+	MEMBARRIER_CMD_PRIVATE_EXPEDITED	= (1 << 3),
 };
 
 #endif /* _UAPI_LINUX_MEMBARRIER_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 4cb8e8b23c6e..9c323a6daa46 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -108,7 +108,6 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
 obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
 obj-$(CONFIG_TORTURE_TEST) += torture.o
-obj-$(CONFIG_MEMBARRIER) += membarrier.o
 
 obj-$(CONFIG_HAS_IOMEM) += memremap.o
 
diff --git a/kernel/membarrier.c b/kernel/membarrier.c
deleted file mode 100644
index 9f9284f37f8d..000000000000
--- a/kernel/membarrier.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * Copyright (C) 2010, 2015 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
- *
- * membarrier system call
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include <linux/syscalls.h>
-#include <linux/membarrier.h>
-#include <linux/tick.h>
-
-/*
- * Bitmask made from a "or" of all commands within enum membarrier_cmd,
- * except MEMBARRIER_CMD_QUERY.
- */
-#define MEMBARRIER_CMD_BITMASK	(MEMBARRIER_CMD_SHARED)
-
-/**
- * sys_membarrier - issue memory barriers on a set of threads
- * @cmd:   Takes command values defined in enum membarrier_cmd.
- * @flags: Currently needs to be 0. For future extensions.
- *
- * If this system call is not implemented, -ENOSYS is returned. If the
- * command specified does not exist, or if the command argument is invalid,
- * this system call returns -EINVAL. For a given command, with flags argument
- * set to 0, this system call is guaranteed to always return the same value
- * until reboot.
- *
- * All memory accesses performed in program order from each targeted thread
- * is guaranteed to be ordered with respect to sys_membarrier(). If we use
- * the semantic "barrier()" to represent a compiler barrier forcing memory
- * accesses to be performed in program order across the barrier, and
- * smp_mb() to represent explicit memory barriers forcing full memory
- * ordering across the barrier, we have the following ordering table for
- * each pair of barrier(), sys_membarrier() and smp_mb():
- *
- * The pair ordering is detailed as (O: ordered, X: not ordered):
- *
- *                        barrier()   smp_mb() sys_membarrier()
- *        barrier()          X           X            O
- *        smp_mb()           X           O            O
- *        sys_membarrier()   O           O            O
- */
-SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
-{
-	/* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
-	if (tick_nohz_full_enabled())
-		return -ENOSYS;
-	if (unlikely(flags))
-		return -EINVAL;
-	switch (cmd) {
-	case MEMBARRIER_CMD_QUERY:
-		return MEMBARRIER_CMD_BITMASK;
-	case MEMBARRIER_CMD_SHARED:
-		if (num_online_cpus() > 1)
-			synchronize_sched();
-		return 0;
-	default:
-		return -EINVAL;
-	}
-}
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 53f0164ed362..78f54932ea1d 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_SCHED_DEBUG) += debug.o
 obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
 obj-$(CONFIG_CPU_FREQ) += cpufreq.o
 obj-$(CONFIG_CPU_FREQ_GOV_SCHEDUTIL) += cpufreq_schedutil.o
+obj-$(CONFIG_MEMBARRIER) += membarrier.o
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bfee6ea7db49..f77269c6c2f8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2640,6 +2640,16 @@ static struct rq *finish_task_switch(struct task_struct *prev)
 	prev_state = prev->state;
 	vtime_task_switch(prev);
 	perf_event_task_sched_in(prev, current);
+	/*
+	 * The membarrier system call requires a full memory barrier
+	 * after storing to rq->curr, before going back to user-space.
+	 *
+	 * TODO: This smp_mb__after_unlock_lock can go away if PPC end
+	 * up adding a full barrier to switch_mm(), or we should figure
+	 * out if a smp_mb__after_unlock_lock is really the proper API
+	 * to use.
+	 */
+	smp_mb__after_unlock_lock();
 	finish_lock_switch(rq, prev);
 	finish_arch_post_lock_switch();
 
@@ -3329,6 +3339,21 @@ static void __sched notrace __schedule(bool preempt)
 	if (likely(prev != next)) {
 		rq->nr_switches++;
 		rq->curr = next;
+		/*
+		 * The membarrier system call requires each architecture
+		 * to have a full memory barrier after updating
+		 * rq->curr, before returning to user-space. For TSO
+		 * (e.g. x86), the architecture must provide its own
+		 * barrier in switch_mm(). For weakly ordered machines
+		 * for which spin_unlock() acts as a full memory
+		 * barrier, finish_lock_switch() in common code takes
+		 * care of this barrier. For weakly ordered machines for
+		 * which spin_unlock() acts as a RELEASE barrier (only
+		 * arm64 and PowerPC), arm64 has a full barrier in
+		 * switch_to(), and PowerPC has
+		 * smp_mb__after_unlock_lock() before
+		 * finish_lock_switch().
+		 */
 		++*switch_count;
 
 		trace_sched_switch(preempt, prev, next);
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
new file mode 100644
index 000000000000..a92fddc22747
--- /dev/null
+++ b/kernel/sched/membarrier.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) 2010-2017 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+ *
+ * membarrier system call
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/syscalls.h>
+#include <linux/membarrier.h>
+#include <linux/tick.h>
+#include <linux/cpumask.h>
+
+#include "sched.h"	/* for cpu_rq(). */
+
+/*
+ * Bitmask made from a "or" of all commands within enum membarrier_cmd,
+ * except MEMBARRIER_CMD_QUERY.
+ */
+#define MEMBARRIER_CMD_BITMASK	\
+	(MEMBARRIER_CMD_SHARED | MEMBARRIER_CMD_PRIVATE_EXPEDITED)
+
+static void ipi_mb(void *info)
+{
+	smp_mb();	/* IPIs should be serializing but paranoid. */
+}
+
+static void membarrier_private_expedited(void)
+{
+	int cpu;
+	bool fallback = false;
+	cpumask_var_t tmpmask;
+
+	if (num_online_cpus() == 1)
+		return;
+
+	/*
+	 * Matches memory barriers around rq->curr modification in
+	 * scheduler.
+	 */
+	smp_mb();	/* system call entry is not a mb. */
+
+	/*
+	 * Expedited membarrier commands guarantee that they won't
+	 * block, hence the GFP_NOWAIT allocation flag and fallback
+	 * implementation.
+	 */
+	if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) {
+		/* Fallback for OOM. */
+		fallback = true;
+	}
+
+	cpus_read_lock();
+	for_each_online_cpu(cpu) {
+		struct task_struct *p;
+
+		/*
+		 * Skipping the current CPU is OK even through we can be
+		 * migrated at any point. The current CPU, at the point
+		 * where we read raw_smp_processor_id(), is ensured to
+		 * be in program order with respect to the caller
+		 * thread. Therefore, we can skip this CPU from the
+		 * iteration.
+		 */
+		if (cpu == raw_smp_processor_id())
+			continue;
+		rcu_read_lock();
+		p = task_rcu_dereference(&cpu_rq(cpu)->curr);
+		if (p && p->mm == current->mm) {
+			if (!fallback)
+				__cpumask_set_cpu(cpu, tmpmask);
+			else
+				smp_call_function_single(cpu, ipi_mb, NULL, 1);
+		}
+		rcu_read_unlock();
+	}
+	if (!fallback) {
+		smp_call_function_many(tmpmask, ipi_mb, NULL, 1);
+		free_cpumask_var(tmpmask);
+	}
+	cpus_read_unlock();
+
+	/*
+	 * Memory barrier on the caller thread _after_ we finished
+	 * waiting for the last IPI. Matches memory barriers around
+	 * rq->curr modification in scheduler.
+	 */
+	smp_mb();	/* exit from system call is not a mb */
+}
+
+/**
+ * sys_membarrier - issue memory barriers on a set of threads
+ * @cmd:   Takes command values defined in enum membarrier_cmd.
+ * @flags: Currently needs to be 0. For future extensions.
+ *
+ * If this system call is not implemented, -ENOSYS is returned. If the
+ * command specified does not exist, not available on the running
+ * kernel, or if the command argument is invalid, this system call
+ * returns -EINVAL. For a given command, with flags argument set to 0,
+ * this system call is guaranteed to always return the same value until
+ * reboot.
+ *
+ * All memory accesses performed in program order from each targeted thread
+ * is guaranteed to be ordered with respect to sys_membarrier(). If we use
+ * the semantic "barrier()" to represent a compiler barrier forcing memory
+ * accesses to be performed in program order across the barrier, and
+ * smp_mb() to represent explicit memory barriers forcing full memory
+ * ordering across the barrier, we have the following ordering table for
+ * each pair of barrier(), sys_membarrier() and smp_mb():
+ *
+ * The pair ordering is detailed as (O: ordered, X: not ordered):
+ *
+ *                        barrier()   smp_mb() sys_membarrier()
+ *        barrier()          X           X            O
+ *        smp_mb()           X           O            O
+ *        sys_membarrier()   O           O            O
+ */
+SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
+{
+	if (unlikely(flags))
+		return -EINVAL;
+	switch (cmd) {
+	case MEMBARRIER_CMD_QUERY:
+	{
+		int cmd_mask = MEMBARRIER_CMD_BITMASK;
+
+		if (tick_nohz_full_enabled())
+			cmd_mask &= ~MEMBARRIER_CMD_SHARED;
+		return cmd_mask;
+	}
+	case MEMBARRIER_CMD_SHARED:
+		/* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
+		if (tick_nohz_full_enabled())
+			return -EINVAL;
+		if (num_online_cpus() > 1)
+			synchronize_sched();
+		return 0;
+	case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
+		membarrier_private_expedited();
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-07-31 16:13 ` Paul E. McKenney
@ 2017-08-01  0:04   ` Mathieu Desnoyers
  2017-08-01  4:03     ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Mathieu Desnoyers @ 2017-08-01  0:04 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List, linux-kernel,
	Andy Lutomirski

----- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote:

> On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
>> Hi Paul,
>> 
>> Today's linux-next merge of the rcu tree got a conflict in:
>> 
>>   arch/x86/mm/tlb.c
>> 
>> between commit:
>> 
>>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
>> 
>> from the tip tree and commit:
>> 
>>   d7713e8f8b23 ("membarrier: Expedited private command")
>> 
>> from the rcu tree.
>> 
>> I fixed it up (the former removed the comment and the load_cr3(), so I
>> just dropped the commend change in the latter) 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.
> 
> Thank you, Stephen!
> 
> Mathieu, Peter, our commit log reads as if removal of load_cr3() would
> simply result in relying on the ordering provided by the atomic ops
> in switch_mm() for mm_cpumask(), so that only the commit log and the
> comment need changing.
> 
> Please let me know if I am missing something here.

I think you are right. Both load_cr3() and mm_cpumask update operations
(LOCK prefixed) provide the appropriate barriers on x86. So it's just a
matter of adapting the comment to the new reality.

Thanks,

Mathieu

> 
> 							Thanx, Paul

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2017-07-31  3:50 Stephen Rothwell
@ 2017-07-31 16:13 ` Paul E. McKenney
  2017-08-01  0:04   ` Mathieu Desnoyers
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2017-07-31 16:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Andy Lutomirski, Mathieu Desnoyers

On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   arch/x86/mm/tlb.c
> 
> between commit:
> 
>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
> 
> from the tip tree and commit:
> 
>   d7713e8f8b23 ("membarrier: Expedited private command")
> 
> from the rcu tree.
> 
> I fixed it up (the former removed the comment and the load_cr3(), so I
> just dropped the commend change in the latter) 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.

Thank you, Stephen!

Mathieu, Peter, our commit log reads as if removal of load_cr3() would
simply result in relying on the ordering provided by the atomic ops
in switch_mm() for mm_cpumask(), so that only the commit log and the
comment need changing.

Please let me know if I am missing something here.

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2017-07-31  3:50 Stephen Rothwell
  2017-07-31 16:13 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2017-07-31  3:50 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Andy Lutomirski, Mathieu Desnoyers

Hi Paul,

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

  arch/x86/mm/tlb.c

between commit:

  94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")

from the tip tree and commit:

  d7713e8f8b23 ("membarrier: Expedited private command")

from the rcu tree.

I fixed it up (the former removed the comment and the load_cr3(), so I
just dropped the commend change in the latter) 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] 71+ messages in thread

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2016-07-18  5:26 Stephen Rothwell
@ 2016-07-19  3:00 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2016-07-19  3:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Anna-Maria Gleixner

On Mon, Jul 18, 2016 at 03:26:28PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   4df8374254ea ("rcu: Convert rcutree to hotplug state machine")
> 
> from the tip tree and commit:
> 
>   2a84cde733b0 ("rcu: Exact CPU-online tracking for RCU")
> 
> from the rcu 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.

Ah, that is in -tip now?  Easier to test, then!

Thank you, the patch looks good at first glance, but will beat it up
a bit.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree.c
> index e5164deb51e1,5663d1e899d3..000000000000
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@@ -3812,54 -3809,34 +3809,80 @@@ int rcutree_prepare_cpu(unsigned int cp
>   
>   	for_each_rcu_flavor(rsp)
>   		rcu_init_percpu_data(cpu, rsp);
>  +
>  +	rcu_prepare_kthreads(cpu);
>  +	rcu_spawn_all_nocb_kthreads(cpu);
>  +
>  +	return 0;
>  +}
>  +
>  +static void rcutree_affinity_setting(unsigned int cpu, int outgoing)
>  +{
>  +	struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
>  +
>  +	rcu_boost_kthread_setaffinity(rdp->mynode, outgoing);
>  +}
>  +
>  +int rcutree_online_cpu(unsigned int cpu)
>  +{
>  +	sync_sched_exp_online_cleanup(cpu);
>  +	rcutree_affinity_setting(cpu, -1);
>  +	return 0;
>  +}
>  +
>  +int rcutree_offline_cpu(unsigned int cpu)
>  +{
>  +	rcutree_affinity_setting(cpu, cpu);
>  +	return 0;
>  +}
>  +
>  +
>  +int rcutree_dying_cpu(unsigned int cpu)
>  +{
>  +	struct rcu_state *rsp;
>  +
>  +	for_each_rcu_flavor(rsp)
>  +		rcu_cleanup_dying_cpu(rsp);
>  +	return 0;
>  +}
>  +
>  +int rcutree_dead_cpu(unsigned int cpu)
>  +{
>  +	struct rcu_state *rsp;
>  +
>  +	for_each_rcu_flavor(rsp) {
>  +		rcu_cleanup_dead_cpu(cpu, rsp);
>  +		do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu));
>  +	}
>  +	return 0;
>   }
>   
> + /*
> +  * Mark the specified CPU as being online so that subsequent grace periods
> +  * (both expedited and normal) will wait on it.  Note that this means that
> +  * incoming CPUs are not allowed to use RCU read-side critical sections
> +  * until this function is called.  Failing to observe this restriction
> +  * will result in lockdep splats.
> +  */
> + void rcu_cpu_starting(unsigned int cpu)
> + {
> + 	unsigned long flags;
> + 	unsigned long mask;
> + 	struct rcu_data *rdp;
> + 	struct rcu_node *rnp;
> + 	struct rcu_state *rsp;
> + 
> + 	for_each_rcu_flavor(rsp) {
> + 		rdp = this_cpu_ptr(rsp->rda);
> + 		rnp = rdp->mynode;
> + 		mask = rdp->grpmask;
> + 		raw_spin_lock_irqsave_rcu_node(rnp, flags);
> + 		rnp->qsmaskinitnext |= mask;
> + 		rnp->expmaskinitnext |= mask;
> + 		raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> + 	}
> + }
> + 
>   #ifdef CONFIG_HOTPLUG_CPU
>   /*
>    * The CPU is exiting the idle loop into the arch_cpu_idle_dead()
> @@@ -4208,9 -4231,12 +4231,11 @@@ void __init rcu_init(void
>   	 * this is called early in boot, before either interrupts
>   	 * or the scheduler are operational.
>   	 */
>  -	cpu_notifier(rcu_cpu_notify, 0);
>   	pm_notifier(rcu_pm_notify, 0);
> - 	for_each_online_cpu(cpu)
> + 	for_each_online_cpu(cpu) {
>  -		rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
>  +		rcutree_prepare_cpu(cpu);
> + 		rcu_cpu_starting(cpu);
> + 	}
>   }
>   
>   #include "tree_exp.h"
> 

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2016-07-18  5:26 Stephen Rothwell
  2016-07-19  3:00 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2016-07-18  5:26 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Anna-Maria Gleixner

Hi Paul,

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

  kernel/rcu/tree.c

between commit:

  4df8374254ea ("rcu: Convert rcutree to hotplug state machine")

from the tip tree and commit:

  2a84cde733b0 ("rcu: Exact CPU-online tracking for RCU")

from the rcu 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/rcu/tree.c
index e5164deb51e1,5663d1e899d3..000000000000
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -3812,54 -3809,34 +3809,80 @@@ int rcutree_prepare_cpu(unsigned int cp
  
  	for_each_rcu_flavor(rsp)
  		rcu_init_percpu_data(cpu, rsp);
 +
 +	rcu_prepare_kthreads(cpu);
 +	rcu_spawn_all_nocb_kthreads(cpu);
 +
 +	return 0;
 +}
 +
 +static void rcutree_affinity_setting(unsigned int cpu, int outgoing)
 +{
 +	struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
 +
 +	rcu_boost_kthread_setaffinity(rdp->mynode, outgoing);
 +}
 +
 +int rcutree_online_cpu(unsigned int cpu)
 +{
 +	sync_sched_exp_online_cleanup(cpu);
 +	rcutree_affinity_setting(cpu, -1);
 +	return 0;
 +}
 +
 +int rcutree_offline_cpu(unsigned int cpu)
 +{
 +	rcutree_affinity_setting(cpu, cpu);
 +	return 0;
 +}
 +
 +
 +int rcutree_dying_cpu(unsigned int cpu)
 +{
 +	struct rcu_state *rsp;
 +
 +	for_each_rcu_flavor(rsp)
 +		rcu_cleanup_dying_cpu(rsp);
 +	return 0;
 +}
 +
 +int rcutree_dead_cpu(unsigned int cpu)
 +{
 +	struct rcu_state *rsp;
 +
 +	for_each_rcu_flavor(rsp) {
 +		rcu_cleanup_dead_cpu(cpu, rsp);
 +		do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu));
 +	}
 +	return 0;
  }
  
+ /*
+  * Mark the specified CPU as being online so that subsequent grace periods
+  * (both expedited and normal) will wait on it.  Note that this means that
+  * incoming CPUs are not allowed to use RCU read-side critical sections
+  * until this function is called.  Failing to observe this restriction
+  * will result in lockdep splats.
+  */
+ void rcu_cpu_starting(unsigned int cpu)
+ {
+ 	unsigned long flags;
+ 	unsigned long mask;
+ 	struct rcu_data *rdp;
+ 	struct rcu_node *rnp;
+ 	struct rcu_state *rsp;
+ 
+ 	for_each_rcu_flavor(rsp) {
+ 		rdp = this_cpu_ptr(rsp->rda);
+ 		rnp = rdp->mynode;
+ 		mask = rdp->grpmask;
+ 		raw_spin_lock_irqsave_rcu_node(rnp, flags);
+ 		rnp->qsmaskinitnext |= mask;
+ 		rnp->expmaskinitnext |= mask;
+ 		raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+ 	}
+ }
+ 
  #ifdef CONFIG_HOTPLUG_CPU
  /*
   * The CPU is exiting the idle loop into the arch_cpu_idle_dead()
@@@ -4208,9 -4231,12 +4231,11 @@@ void __init rcu_init(void
  	 * this is called early in boot, before either interrupts
  	 * or the scheduler are operational.
  	 */
 -	cpu_notifier(rcu_cpu_notify, 0);
  	pm_notifier(rcu_pm_notify, 0);
- 	for_each_online_cpu(cpu)
+ 	for_each_online_cpu(cpu) {
 -		rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
 +		rcutree_prepare_cpu(cpu);
+ 		rcu_cpu_starting(cpu);
+ 	}
  }
  
  #include "tree_exp.h"

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2016-06-09  5:14 Stephen Rothwell
@ 2016-06-09 15:59 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2016-06-09 15:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Thu, Jun 09, 2016 at 03:14:41PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   6428671bae97 ("locking/mutex: Optimize mutex_trylock() fast-path")
> 
> from the tip tree and commit:
> 
>   3991b105efd5 ("rcu: Move expedited code from tree.c to tree_exp.h")
> 
> from the rcu tree.
> 
> I fixed it up (I used tree.c from the rcu tree and then applied the
> following fic up patch) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging.  You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 9 Jun 2016 15:01:10 +1000
> Subject: [PATCH] rcu: merge fix for kernel/rcu/tree_exp.h
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Looks correct to me, thank you!

							Thanx, Paul

> ---
>  kernel/rcu/tree_exp.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index d400434af6b2..6d86ab6ec2c9 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -253,7 +253,6 @@ static bool exp_funnel_lock(struct rcu_state *rsp, unsigned long s)
>  	if (ULONG_CMP_LT(READ_ONCE(rnp->exp_seq_rq), s) &&
>  	    (rnp == rnp_root ||
>  	     ULONG_CMP_LT(READ_ONCE(rnp_root->exp_seq_rq), s)) &&
> -	    !mutex_is_locked(&rsp->exp_mutex) &&
>  	    mutex_trylock(&rsp->exp_mutex))
>  		goto fastpath;
> 
> -- 
> 2.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2016-06-09  5:14 Stephen Rothwell
  2016-06-09 15:59 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2016-06-09  5:14 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel

Hi Paul,

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

  kernel/rcu/tree.c

between commit:

  6428671bae97 ("locking/mutex: Optimize mutex_trylock() fast-path")

from the tip tree and commit:

  3991b105efd5 ("rcu: Move expedited code from tree.c to tree_exp.h")

from the rcu tree.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 9 Jun 2016 15:01:10 +1000
Subject: [PATCH] rcu: merge fix for kernel/rcu/tree_exp.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/rcu/tree_exp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index d400434af6b2..6d86ab6ec2c9 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -253,7 +253,6 @@ static bool exp_funnel_lock(struct rcu_state *rsp, unsigned long s)
 	if (ULONG_CMP_LT(READ_ONCE(rnp->exp_seq_rq), s) &&
 	    (rnp == rnp_root ||
 	     ULONG_CMP_LT(READ_ONCE(rnp_root->exp_seq_rq), s)) &&
-	    !mutex_is_locked(&rsp->exp_mutex) &&
 	    mutex_trylock(&rsp->exp_mutex))
 		goto fastpath;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2016-03-04  4:13 Stephen Rothwell
@ 2016-03-04 15:04 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2016-03-04 15:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Boqun Feng

On Fri, Mar 04, 2016 at 03:13:06PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   27d50c7eeb0f ("rcu: Make CPU_DYING_IDLE an explicit call")
> 
> from the tip tree and commit:
> 
>   67c583a7de34 ("RCU: Privatize rcu_node::lock")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thank you!  I have applied this resolution to -rcu and am testing it.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree.c
> index 0bbc1497a0e4,55cea189783f..000000000000
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@@ -4227,43 -4246,6 +4224,43 @@@ static void rcu_prepare_cpu(int cpu
>   		rcu_init_percpu_data(cpu, rsp);
>   }
>   
>  +#ifdef CONFIG_HOTPLUG_CPU
>  +/*
>  + * The CPU is exiting the idle loop into the arch_cpu_idle_dead()
>  + * function.  We now remove it from the rcu_node tree's ->qsmaskinit
>  + * bit masks.
>  + */
>  +static void rcu_cleanup_dying_idle_cpu(int cpu, struct rcu_state *rsp)
>  +{
>  +	unsigned long flags;
>  +	unsigned long mask;
>  +	struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
>  +	struct rcu_node *rnp = rdp->mynode;  /* Outgoing CPU's rdp & rnp. */
>  +
>  +	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
>  +		return;
>  +
>  +	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
>  +	mask = rdp->grpmask;
>  +	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
>  +	rnp->qsmaskinitnext &= ~mask;
> - 	raw_spin_unlock_irqrestore(&rnp->lock, flags);
> ++	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
>  +}
>  +
>  +void rcu_report_dead(unsigned int cpu)
>  +{
>  +	struct rcu_state *rsp;
>  +
>  +	/* QS for any half-done expedited RCU-sched GP. */
>  +	preempt_disable();
>  +	rcu_report_exp_rdp(&rcu_sched_state,
>  +			   this_cpu_ptr(rcu_sched_state.rda), true);
>  +	preempt_enable();
>  +	for_each_rcu_flavor(rsp)
>  +		rcu_cleanup_dying_idle_cpu(cpu, rsp);
>  +}
>  +#endif
>  +
>   /*
>    * Handle CPU online/offline notification events.
>    */
> 

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2016-03-04  4:13 Stephen Rothwell
  2016-03-04 15:04 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2016-03-04  4:13 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Boqun Feng

Hi Paul,

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

  kernel/rcu/tree.c

between commit:

  27d50c7eeb0f ("rcu: Make CPU_DYING_IDLE an explicit call")

from the tip tree and commit:

  67c583a7de34 ("RCU: Privatize rcu_node::lock")

from the rcu tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/rcu/tree.c
index 0bbc1497a0e4,55cea189783f..000000000000
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -4227,43 -4246,6 +4224,43 @@@ static void rcu_prepare_cpu(int cpu
  		rcu_init_percpu_data(cpu, rsp);
  }
  
 +#ifdef CONFIG_HOTPLUG_CPU
 +/*
 + * The CPU is exiting the idle loop into the arch_cpu_idle_dead()
 + * function.  We now remove it from the rcu_node tree's ->qsmaskinit
 + * bit masks.
 + */
 +static void rcu_cleanup_dying_idle_cpu(int cpu, struct rcu_state *rsp)
 +{
 +	unsigned long flags;
 +	unsigned long mask;
 +	struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
 +	struct rcu_node *rnp = rdp->mynode;  /* Outgoing CPU's rdp & rnp. */
 +
 +	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
 +		return;
 +
 +	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 +	mask = rdp->grpmask;
 +	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 +	rnp->qsmaskinitnext &= ~mask;
- 	raw_spin_unlock_irqrestore(&rnp->lock, flags);
++	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
 +}
 +
 +void rcu_report_dead(unsigned int cpu)
 +{
 +	struct rcu_state *rsp;
 +
 +	/* QS for any half-done expedited RCU-sched GP. */
 +	preempt_disable();
 +	rcu_report_exp_rdp(&rcu_sched_state,
 +			   this_cpu_ptr(rcu_sched_state.rda), true);
 +	preempt_enable();
 +	for_each_rcu_flavor(rsp)
 +		rcu_cleanup_dying_idle_cpu(cpu, rsp);
 +}
 +#endif
 +
  /*
   * Handle CPU online/offline notification events.
   */

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2015-07-16  2:57 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2015-07-16  2:57 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski

Hi Paul,

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

  arch/x86/kernel/traps.c

between commit:

  8c84014f3bbb ("x86/entry: Remove exception_enter() from most trap handlers")

from the tip tree and commit:

  02300fdb3e5f ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")

from the rcu 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/kernel/traps.c
index 8e65d8a9b8db,c5a5231d1d11..000000000000
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@@ -131,14 -136,19 +131,14 @@@ void ist_enter(struct pt_regs *regs
  	preempt_count_add(HARDIRQ_OFFSET);
  
  	/* This code is a bit fragile.  Test it. */
- 	rcu_lockdep_assert(rcu_is_watching(), "ist_enter didn't work");
+ 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "ist_enter didn't work");
 -
 -	return prev_state;
  }
  
 -void ist_exit(struct pt_regs *regs, enum ctx_state prev_state)
 +void ist_exit(struct pt_regs *regs)
  {
 -	/* Must be before exception_exit. */
  	preempt_count_sub(HARDIRQ_OFFSET);
  
 -	if (user_mode(regs))
 -		return exception_exit(prev_state);
 -	else
 +	if (!user_mode(regs))
  		rcu_nmi_exit();
  }
  

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2015-05-07  3:56 Stephen Rothwell
  0 siblings, 0 replies; 71+ messages in thread
From: Stephen Rothwell @ 2015-05-07  3:56 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel

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

Hi Paul,

Today's linux-next merge of the rcu tree got conflicts in
include/linux/rcupdate.h, include/linux/rcutree.h and
kernel/rcu/tree_plugin.h between commit c1ad348b452a ("tick: Nohz:
Rework next timer evaluation") from the tip tree and commit
f49f794683d6 ("rcu: Eliminate a few CONFIG_RCU_NOCB_CPU_ALL #ifdefs")
from the rcu tree.

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

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

diff --cc include/linux/rcupdate.h
index 0627a447c589,03a899aabd17..000000000000
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@@ -1155,13 -1099,13 +1101,13 @@@ static inline notrace void rcu_read_unl
  #define kfree_rcu(ptr, rcu_head)					\
  	__kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
  
- #if defined(CONFIG_TINY_RCU) || defined(CONFIG_RCU_NOCB_CPU_ALL)
+ #ifdef CONFIG_TINY_RCU
 -static inline int rcu_needs_cpu(unsigned long *delta_jiffies)
 +static inline int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
 -	*delta_jiffies = ULONG_MAX;
 +	*nextevt = KTIME_MAX;
  	return 0;
  }
- #endif /* #if defined(CONFIG_TINY_RCU) || defined(CONFIG_RCU_NOCB_CPU_ALL) */
+ #endif /* #ifdef CONFIG_TINY_RCU */
  
  #if defined(CONFIG_RCU_NOCB_CPU_ALL)
  static inline bool rcu_is_nocb_cpu(int cpu) { return true; }
diff --cc include/linux/rcutree.h
index db2e31beaae7,3fa4a43ab415..000000000000
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@@ -31,9 -31,7 +31,7 @@@
  #define __LINUX_RCUTREE_H
  
  void rcu_note_context_switch(void);
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *delta_jiffies);
 +int rcu_needs_cpu(u64 basem, u64 *nextevt);
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  void rcu_cpu_stall_reset(void);
  
  /*
diff --cc kernel/rcu/tree_plugin.h
index 0ef80a0bbabb,a2f64e4fdb57..000000000000
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@@ -1367,13 -1375,12 +1375,12 @@@ static void rcu_prepare_kthreads(int cp
   * Because we not have RCU_FAST_NO_HZ, just check whether this CPU needs
   * any flavor of RCU.
   */
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *delta_jiffies)
 +int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
 -	*delta_jiffies = ULONG_MAX;
 +	*nextevt = KTIME_MAX;
- 	return rcu_cpu_has_callbacks(NULL);
+ 	return IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL)
+ 	       ? 0 : rcu_cpu_has_callbacks(NULL);
  }
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  
  /*
   * Because we do not have RCU_FAST_NO_HZ, don't bother cleaning up
@@@ -1480,12 -1487,15 +1487,16 @@@ static bool __maybe_unused rcu_try_adva
   *
   * The caller must have disabled interrupts.
   */
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *dj)
 +int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
  	struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
 +	unsigned long dj;
  
+ 	if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL)) {
 -		*dj = ULONG_MAX;
++		*nextevt = KTIME_MAX;
+ 		return 0;
+ 	}
+ 
  	/* Snapshot to detect later posting of non-lazy callback. */
  	rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
  
@@@ -1505,15 -1515,13 +1516,14 @@@
  
  	/* Request timer delay depending on laziness, and round. */
  	if (!rdtp->all_lazy) {
 -		*dj = round_up(rcu_idle_gp_delay + jiffies,
 +		dj = round_up(rcu_idle_gp_delay + jiffies,
  			       rcu_idle_gp_delay) - jiffies;
  	} else {
 -		*dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies;
 +		dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies;
  	}
 +	*nextevt = basemono + dj * TICK_NSEC;
  	return 0;
  }
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  
  /*
   * Prepare a CPU for idle from an RCU perspective.  The first major task

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2014-02-24  4:18 Stephen Rothwell
@ 2014-02-24  4:42 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2014-02-24  4:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Dongsheng Yang

On Mon, Feb 24, 2014 at 03:18:01PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcu/rcutorture.c between commit d277d868dab6 ("rcu: Use MAX_NICE
> to replace hardcoding of 19") from the tip tree (where this file is
> called kernel/rcu/torture.c) and commit 5ccf60f23d33 ("rcutorture: Rename
> PRINTK to TOROUT") from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Hello, Stephen,

Looks correct at first glance, thank you!

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc kernel/rcu/rcutorture.c
> index 219761db1a46,f59d48597dde..000000000000
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@@ -802,10 -693,10 +693,10 @@@ rcu_torture_writer(void *arg
>   	struct rcu_torture *rp;
>   	struct rcu_torture *rp1;
>   	struct rcu_torture *old_rp;
> - 	static DEFINE_RCU_RANDOM(rand);
> + 	static DEFINE_TORTURE_RANDOM(rand);
>   
> - 	VERBOSE_PRINTK_STRING("rcu_torture_writer task started");
> + 	VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
>  -	set_user_nice(current, 19);
>  +	set_user_nice(current, MAX_NICE);
>   
>   	do {
>   		schedule_timeout_uninterruptible(1);
> @@@ -868,19 -756,19 +756,19 @@@
>   static int
>   rcu_torture_fakewriter(void *arg)
>   {
> - 	DEFINE_RCU_RANDOM(rand);
> + 	DEFINE_TORTURE_RANDOM(rand);
>   
> - 	VERBOSE_PRINTK_STRING("rcu_torture_fakewriter task started");
> + 	VERBOSE_TOROUT_STRING("rcu_torture_fakewriter task started");
>  -	set_user_nice(current, 19);
>  +	set_user_nice(current, MAX_NICE);
>   
>   	do {
> - 		schedule_timeout_uninterruptible(1 + rcu_random(&rand)%10);
> - 		udelay(rcu_random(&rand) & 0x3ff);
> + 		schedule_timeout_uninterruptible(1 + torture_random(&rand)%10);
> + 		udelay(torture_random(&rand) & 0x3ff);
>   		if (cur_ops->cb_barrier != NULL &&
> - 		    rcu_random(&rand) % (nfakewriters * 8) == 0) {
> + 		    torture_random(&rand) % (nfakewriters * 8) == 0) {
>   			cur_ops->cb_barrier();
>   		} else if (gp_normal == gp_exp) {
> - 			if (rcu_random(&rand) & 0x80)
> + 			if (torture_random(&rand) & 0x80)
>   				cur_ops->sync();
>   			else
>   				cur_ops->exp_sync();
> @@@ -986,8 -871,8 +871,8 @@@ rcu_torture_reader(void *arg
>   	struct timer_list t;
>   	unsigned long long ts;
>   
> - 	VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
> + 	VERBOSE_TOROUT_STRING("rcu_torture_reader task started");
>  -	set_user_nice(current, 19);
>  +	set_user_nice(current, MAX_NICE);
>   	if (irqreader && cur_ops->irq_capable)
>   		setup_timer_on_stack(&t, rcu_torture_timer, 0);
>   
> @@@ -1583,8 -1160,8 +1160,8 @@@ static int rcu_torture_barrier_cbs(voi
>   	struct rcu_head rcu;
>   
>   	init_rcu_head_on_stack(&rcu);
> - 	VERBOSE_PRINTK_STRING("rcu_torture_barrier_cbs task started");
> + 	VERBOSE_TOROUT_STRING("rcu_torture_barrier_cbs task started");
>  -	set_user_nice(current, 19);
>  +	set_user_nice(current, MAX_NICE);
>   	do {
>   		wait_event(barrier_cbs_wq[myid],
>   			   (newphase =

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2014-02-24  4:18 Stephen Rothwell
  2014-02-24  4:42 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2014-02-24  4:18 UTC (permalink / raw)
  To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Dongsheng Yang

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

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/rcu/rcutorture.c between commit d277d868dab6 ("rcu: Use MAX_NICE
to replace hardcoding of 19") from the tip tree (where this file is
called kernel/rcu/torture.c) and commit 5ccf60f23d33 ("rcutorture: Rename
PRINTK to TOROUT") from the rcu 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/rcu/rcutorture.c
index 219761db1a46,f59d48597dde..000000000000
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@@ -802,10 -693,10 +693,10 @@@ rcu_torture_writer(void *arg
  	struct rcu_torture *rp;
  	struct rcu_torture *rp1;
  	struct rcu_torture *old_rp;
- 	static DEFINE_RCU_RANDOM(rand);
+ 	static DEFINE_TORTURE_RANDOM(rand);
  
- 	VERBOSE_PRINTK_STRING("rcu_torture_writer task started");
+ 	VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
 -	set_user_nice(current, 19);
 +	set_user_nice(current, MAX_NICE);
  
  	do {
  		schedule_timeout_uninterruptible(1);
@@@ -868,19 -756,19 +756,19 @@@
  static int
  rcu_torture_fakewriter(void *arg)
  {
- 	DEFINE_RCU_RANDOM(rand);
+ 	DEFINE_TORTURE_RANDOM(rand);
  
- 	VERBOSE_PRINTK_STRING("rcu_torture_fakewriter task started");
+ 	VERBOSE_TOROUT_STRING("rcu_torture_fakewriter task started");
 -	set_user_nice(current, 19);
 +	set_user_nice(current, MAX_NICE);
  
  	do {
- 		schedule_timeout_uninterruptible(1 + rcu_random(&rand)%10);
- 		udelay(rcu_random(&rand) & 0x3ff);
+ 		schedule_timeout_uninterruptible(1 + torture_random(&rand)%10);
+ 		udelay(torture_random(&rand) & 0x3ff);
  		if (cur_ops->cb_barrier != NULL &&
- 		    rcu_random(&rand) % (nfakewriters * 8) == 0) {
+ 		    torture_random(&rand) % (nfakewriters * 8) == 0) {
  			cur_ops->cb_barrier();
  		} else if (gp_normal == gp_exp) {
- 			if (rcu_random(&rand) & 0x80)
+ 			if (torture_random(&rand) & 0x80)
  				cur_ops->sync();
  			else
  				cur_ops->exp_sync();
@@@ -986,8 -871,8 +871,8 @@@ rcu_torture_reader(void *arg
  	struct timer_list t;
  	unsigned long long ts;
  
- 	VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
+ 	VERBOSE_TOROUT_STRING("rcu_torture_reader task started");
 -	set_user_nice(current, 19);
 +	set_user_nice(current, MAX_NICE);
  	if (irqreader && cur_ops->irq_capable)
  		setup_timer_on_stack(&t, rcu_torture_timer, 0);
  
@@@ -1583,8 -1160,8 +1160,8 @@@ static int rcu_torture_barrier_cbs(voi
  	struct rcu_head rcu;
  
  	init_rcu_head_on_stack(&rcu);
- 	VERBOSE_PRINTK_STRING("rcu_torture_barrier_cbs task started");
+ 	VERBOSE_TOROUT_STRING("rcu_torture_barrier_cbs task started");
 -	set_user_nice(current, 19);
 +	set_user_nice(current, MAX_NICE);
  	do {
  		wait_event(barrier_cbs_wq[myid],
  			   (newphase =

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2012-09-05 16:39 ` Paul E. McKenney
@ 2012-09-05 17:11   ` Peter Zijlstra
  0 siblings, 0 replies; 71+ messages in thread
From: Peter Zijlstra @ 2012-09-05 17:11 UTC (permalink / raw)
  To: paulmck
  Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin

On Wed, 2012-09-05 at 09:39 -0700, Paul E. McKenney wrote:
> On Wed, Sep 05, 2012 at 01:59:47PM +1000, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > Today's linux-next merge of the rcu tree got a conflict in
> > kernel/sched/core.c between commit f319da0c6894 ("sched: Fix load avg vs
> > cpu-hotplug") from the tip tree and commit ead504e5600e ("sched: Fix load
> > avg vs cpu-hotplug") from the rcu tree.
> > 
> > These are 2 slightly different versions of the same patch :-( Same author
> > time, different commit times ...  The rcu tree version contains this
> > extra bit in the commit message:
> > 
> > "    [ paulmck: Move call to calc_load_migration to CPU_DEAD to avoid
> >      miscounting noted by Rakib. ]"
> > 
> > So I used it.  Let me know if this is not correct.
> 
> My guess is that Peter Zijlstra will replace my version at some point,
> at which point I will drop mine.  But from what I can see, the version
> currently  in -tip is the older version, so I will keep mine until
> -tip updates.

Yeah, that was a fail on my part. I'll go sort it after dinner.

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2012-09-05  3:59 Stephen Rothwell
@ 2012-09-05 16:39 ` Paul E. McKenney
  2012-09-05 17:11   ` Peter Zijlstra
  0 siblings, 1 reply; 71+ messages in thread
From: Paul E. McKenney @ 2012-09-05 16:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

On Wed, Sep 05, 2012 at 01:59:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/sched/core.c between commit f319da0c6894 ("sched: Fix load avg vs
> cpu-hotplug") from the tip tree and commit ead504e5600e ("sched: Fix load
> avg vs cpu-hotplug") from the rcu tree.
> 
> These are 2 slightly different versions of the same patch :-( Same author
> time, different commit times ...  The rcu tree version contains this
> extra bit in the commit message:
> 
> "    [ paulmck: Move call to calc_load_migration to CPU_DEAD to avoid
>      miscounting noted by Rakib. ]"
> 
> So I used it.  Let me know if this is not correct.

My guess is that Peter Zijlstra will replace my version at some point,
at which point I will drop mine.  But from what I can see, the version
currently  in -tip is the older version, so I will keep mine until
-tip updates.

							Thanx, Paul

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2012-09-05  3:59 Stephen Rothwell
  2012-09-05 16:39 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2012-09-05  3:59 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

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

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/sched/core.c between commit f319da0c6894 ("sched: Fix load avg vs
cpu-hotplug") from the tip tree and commit ead504e5600e ("sched: Fix load
avg vs cpu-hotplug") from the rcu tree.

These are 2 slightly different versions of the same patch :-( Same author
time, different commit times ...  The rcu tree version contains this
extra bit in the commit message:

"    [ paulmck: Move call to calc_load_migration to CPU_DEAD to avoid
     miscounting noted by Rakib. ]"

So I used it.  Let me know if this is not correct.

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

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2012-08-23  3:01 Stephen Rothwell
@ 2012-08-23  3:22 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2012-08-23  3:22 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Frederic Weisbecker, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra

On Thu, Aug 23, 2012 at 01:01:43PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in arch/Kconfig
> between commit b952741c8079 ("cputime: Generalize
> CONFIG_VIRT_CPU_ACCOUNTING") from the tip tree and commit 3dbdfc26e27f
> ("rcu: Settle config for userspace extended quiescent state") from the
> rcu tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Looks good, thank you!

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/Kconfig
> index 07db929,1c7c9be..0000000
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@@ -294,26 -274,14 +294,36 @@@ config SECCOMP_FILTE
>   
>   	  See Documentation/prctl/seccomp_filter.txt for details.
>   
>  +config HAVE_MOD_ARCH_SPECIFIC
>  +	bool
>  +	help
>  +	  The arch uses struct mod_arch_specific to store data.  Many arches
>  +	  just need a simple module loader without arch specific data - those
>  +	  should not enable this.
>  +
>  +config MODULES_USE_ELF_RELA
>  +	bool
>  +	help
>  +	  Modules only use ELF RELA relocations.  Modules with ELF REL
>  +	  relocations will give an error.
>  +
>  +config MODULES_USE_ELF_REL
>  +	bool
>  +	help
>  +	  Modules only use ELF REL relocations.  Modules with ELF RELA
>  +	  relocations will give an error.
>  +
>  +config HAVE_VIRT_CPU_ACCOUNTING
>  +	bool
>  +
> + config HAVE_RCU_USER_QS
> + 	bool
> + 	help
> + 	  Provide kernel entry/exit hooks necessary for userspace
> + 	  RCU extended quiescent state. Syscalls need to be wrapped inside
> + 	  rcu_user_exit()-rcu_user_enter() through the slow path using
> + 	  TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
> + 	  are already protected inside rcu_irq_enter/rcu_irq_exit() but
> + 	  preemption or signal handling on irq exit still need to be protected.
> + 
>   source "kernel/gcov/Kconfig"

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2012-08-23  3:01 Stephen Rothwell
  2012-08-23  3:22 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2012-08-23  3:01 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Frederic Weisbecker, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra

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

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in arch/Kconfig
between commit b952741c8079 ("cputime: Generalize
CONFIG_VIRT_CPU_ACCOUNTING") from the tip tree and commit 3dbdfc26e27f
("rcu: Settle config for userspace extended quiescent state") from the
rcu tree.

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

diff --cc arch/Kconfig
index 07db929,1c7c9be..0000000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -294,26 -274,14 +294,36 @@@ config SECCOMP_FILTE
  
  	  See Documentation/prctl/seccomp_filter.txt for details.
  
 +config HAVE_MOD_ARCH_SPECIFIC
 +	bool
 +	help
 +	  The arch uses struct mod_arch_specific to store data.  Many arches
 +	  just need a simple module loader without arch specific data - those
 +	  should not enable this.
 +
 +config MODULES_USE_ELF_RELA
 +	bool
 +	help
 +	  Modules only use ELF RELA relocations.  Modules with ELF REL
 +	  relocations will give an error.
 +
 +config MODULES_USE_ELF_REL
 +	bool
 +	help
 +	  Modules only use ELF REL relocations.  Modules with ELF RELA
 +	  relocations will give an error.
 +
 +config HAVE_VIRT_CPU_ACCOUNTING
 +	bool
 +
+ config HAVE_RCU_USER_QS
+ 	bool
+ 	help
+ 	  Provide kernel entry/exit hooks necessary for userspace
+ 	  RCU extended quiescent state. Syscalls need to be wrapped inside
+ 	  rcu_user_exit()-rcu_user_enter() through the slow path using
+ 	  TIF_NOHZ flag. Exceptions handlers must be wrapped as well. Irqs
+ 	  are already protected inside rcu_irq_enter/rcu_irq_exit() but
+ 	  preemption or signal handling on irq exit still need to be protected.
+ 
  source "kernel/gcov/Kconfig"

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

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2012-08-22  4:27 Stephen Rothwell
@ 2012-08-22  5:05 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2012-08-22  5:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

On Wed, Aug 22, 2012 at 02:27:35PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcutree.h between commit 62ab7072476a ("rcu: Use
> smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
> and commit daa5d37ff51b ("rcu: Prevent force_quiescent_state() memory
> contention") from the rcu tree.
> 
> Just context changes (I think).  I fixed it up (see below) and can carry
> the fix as necessary.

This one also looks correct.

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc kernel/rcutree.h
> index 1224d4c,c2a3e7d..0000000
> --- a/kernel/rcutree.h
> +++ b/kernel/rcutree.h
> @@@ -196,6 -200,13 +200,7 @@@ struct rcu_node 
>   				/* Refused to boost: not sure why, though. */
>   				/*  This can happen due to race conditions. */
>   #endif /* #ifdef CONFIG_RCU_BOOST */
>  -	struct task_struct *node_kthread_task;
>  -				/* kthread that takes care of this rcu_node */
>  -				/*  structure, for example, awakening the */
>  -				/*  per-CPU kthreads as needed. */
>  -	unsigned int node_kthread_status;
>  -				/* State of node_kthread_task for tracing. */
> + 	raw_spinlock_t fqslock ____cacheline_internodealigned_in_smp;
>   } ____cacheline_internodealigned_in_smp;
>   
>   /*

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

* Re: linux-next: manual merge of the rcu tree with the tip tree
  2012-08-22  4:27 Stephen Rothwell
@ 2012-08-22  5:03 ` Paul E. McKenney
  0 siblings, 0 replies; 71+ messages in thread
From: Paul E. McKenney @ 2012-08-22  5:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

On Wed, Aug 22, 2012 at 02:27:22PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcutree_plugin.h between commit 62ab7072476a ("rcu: Use
> smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
> and commit 8732d57a8ce0 ("rcu: Provide OOM handler to motivate lazy RCU
> callbacks") from the rcu tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

The fix looks correct to me!

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc kernel/rcutree_plugin.h
> index c1961ae,c3e3fc4..0000000
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@@ -25,7 -25,7 +25,8 @@@
>    */
>   
>   #include <linux/delay.h>
>  +#include <linux/smpboot.h>
> + #include <linux/oom.h>
>   
>   #define RCU_KTHREAD_PRIO 1
>   

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2012-08-22  4:27 Stephen Rothwell
  2012-08-22  5:05 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2012-08-22  4:27 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

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

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/rcutree.h between commit 62ab7072476a ("rcu: Use
smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
and commit daa5d37ff51b ("rcu: Prevent force_quiescent_state() memory
contention") from the rcu tree.

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

diff --cc kernel/rcutree.h
index 1224d4c,c2a3e7d..0000000
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@@ -196,6 -200,13 +200,7 @@@ struct rcu_node 
  				/* Refused to boost: not sure why, though. */
  				/*  This can happen due to race conditions. */
  #endif /* #ifdef CONFIG_RCU_BOOST */
 -	struct task_struct *node_kthread_task;
 -				/* kthread that takes care of this rcu_node */
 -				/*  structure, for example, awakening the */
 -				/*  per-CPU kthreads as needed. */
 -	unsigned int node_kthread_status;
 -				/* State of node_kthread_task for tracing. */
+ 	raw_spinlock_t fqslock ____cacheline_internodealigned_in_smp;
  } ____cacheline_internodealigned_in_smp;
  
  /*

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

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

* linux-next: manual merge of the rcu tree with the tip tree
@ 2012-08-22  4:27 Stephen Rothwell
  2012-08-22  5:03 ` Paul E. McKenney
  0 siblings, 1 reply; 71+ messages in thread
From: Stephen Rothwell @ 2012-08-22  4:27 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra

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

Hi Paul,

Today's linux-next merge of the rcu tree got a conflict in
kernel/rcutree_plugin.h between commit 62ab7072476a ("rcu: Use
smp_hotplug_thread facility for RCUs per-CPU kthread") from the tip tree
and commit 8732d57a8ce0 ("rcu: Provide OOM handler to motivate lazy RCU
callbacks") from the rcu tree.

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

diff --cc kernel/rcutree_plugin.h
index c1961ae,c3e3fc4..0000000
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@@ -25,7 -25,7 +25,8 @@@
   */
  
  #include <linux/delay.h>
 +#include <linux/smpboot.h>
+ #include <linux/oom.h>
  
  #define RCU_KTHREAD_PRIO 1
  

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

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

end of thread, other threads:[~2024-02-27  1:55 UTC | newest]

Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-20  4:47 linux-next: manual merge of the rcu tree with the tip tree Stephen Rothwell
2011-06-20 15:17 ` Paul E. McKenney
2012-08-22  4:27 Stephen Rothwell
2012-08-22  5:03 ` Paul E. McKenney
2012-08-22  4:27 Stephen Rothwell
2012-08-22  5:05 ` Paul E. McKenney
2012-08-23  3:01 Stephen Rothwell
2012-08-23  3:22 ` Paul E. McKenney
2012-09-05  3:59 Stephen Rothwell
2012-09-05 16:39 ` Paul E. McKenney
2012-09-05 17:11   ` Peter Zijlstra
2014-02-24  4:18 Stephen Rothwell
2014-02-24  4:42 ` Paul E. McKenney
2015-05-07  3:56 Stephen Rothwell
2015-07-16  2:57 Stephen Rothwell
2016-03-04  4:13 Stephen Rothwell
2016-03-04 15:04 ` Paul E. McKenney
2016-06-09  5:14 Stephen Rothwell
2016-06-09 15:59 ` Paul E. McKenney
2016-07-18  5:26 Stephen Rothwell
2016-07-19  3:00 ` Paul E. McKenney
2017-07-31  3:50 Stephen Rothwell
2017-07-31 16:13 ` Paul E. McKenney
2017-08-01  0:04   ` Mathieu Desnoyers
2017-08-01  4:03     ` Paul E. McKenney
2017-08-01  4:25       ` Mathieu Desnoyers
2017-08-01 16:31         ` Paul E. McKenney
2017-08-01 13:43       ` Andy Lutomirski
2017-08-01 13:58         ` Peter Zijlstra
2017-08-01 14:15           ` Peter Zijlstra
2017-08-01 14:17             ` Andy Lutomirski
2017-08-01 14:02         ` Mathieu Desnoyers
2017-08-01 14:15           ` Andy Lutomirski
2017-08-01 15:40             ` Mathieu Desnoyers
2017-08-01 21:36             ` Paul E. McKenney
2017-08-22  4:13 Stephen Rothwell
2017-11-10  2:14 Stephen Rothwell
2018-06-22  2:27 Stephen Rothwell
2018-06-26 19:33 ` Paul E. McKenney
2019-12-16 23:37 Stephen Rothwell
2019-12-19  0:50 Stephen Rothwell
2019-12-19  1:27 ` Paul E. McKenney
2019-12-19  1:31   ` Paul E. McKenney
2019-12-19  8:41     ` Peter Zijlstra
2019-12-19 13:38       ` Paul E. McKenney
2020-03-25  3:08 Stephen Rothwell
2020-03-25  3:18 ` Paul E. McKenney
2020-03-25 21:31   ` Paul E. McKenney
2020-05-29  6:22 Stephen Rothwell
2020-05-29  6:41 ` Stephen Rothwell
2020-05-29 14:15   ` Paul E. McKenney
2020-05-29 23:38     ` Stephen Rothwell
2020-06-24  3:04 Stephen Rothwell
2020-06-24  4:06 ` Paul E. McKenney
2020-06-25  2:44 Stephen Rothwell
2020-06-25  3:44 ` Paul E. McKenney
2020-06-26  3:14 Stephen Rothwell
2020-07-29  6:23 Stephen Rothwell
2020-10-09  4:59 Stephen Rothwell
2021-06-22  4:47 Stephen Rothwell
2021-06-22  5:04 ` Stephen Rothwell
2021-06-22 17:10 ` Paul E. McKenney
2021-06-22  4:51 Stephen Rothwell
2021-06-23  5:33 Stephen Rothwell
2021-08-17  7:09 Stephen Rothwell
2021-10-12  4:48 Stephen Rothwell
2021-10-13 16:31 ` Paul E. McKenney
2022-02-21 18:17 broonie
2022-04-06  2:45 Stephen Rothwell
2022-04-06 16:28 ` Paul E. McKenney
2024-02-27  1:55 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).