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

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

Hi all,

On Tue, 22 Jun 2021 14:47:57 +1000 Stephen Rothwell [off-list ref] 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

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