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

[Stephen Rothwell]

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


pgprorzzazXn5.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgpD4vygVVksK.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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 
 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 
Date: Fri, 26 Jun 2020 13:02:03 +1000
Subject: [PATCH] merge fix for "rcu: Fixup noinstr warnings"

Signed-off-by: Stephen Rothwell 
---
 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


pgpHCi_2Ff6sg.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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

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

[Stephen Rothwell]

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


pgp71qceBRVdo.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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

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

[Stephen Rothwell]

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


pgpLkSMAZCtwN.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Paul,

On Fri, 29 May 2020 07:15:01 -0700 "Paul E. McKenney"  
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


pgplrhWvQRk25.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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

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

[Stephen Rothwell]

Hi all,

On Fri, 29 May 2020 16:22:34 +1000 Stephen Rothwell  
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.
   *


pgpX9rpHtaw9R.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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


pgphKrOZKx1I_.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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..
> --- 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(>gp_seq, c)));
>   if (likely(d))
>   break;
>   WARN_ON(signal_pending(current));

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

[Paul E. McKenney]

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..
> --- 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(>gp_seq, c)));
>   if (likely(d))
>   break;
>   WARN_ON(signal_pending(current));

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

[Stephen Rothwell]

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..
--- 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(>gp_seq, c)));
if (likely(d))
break;
WARN_ON(signal_pending(current));


pgpDYbxDVCwoz.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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..
--- 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(>gp_seq, c)));
if (likely(d))
break;
WARN_ON(signal_pending(current));


pgpDYbxDVCwoz.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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..
--- 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(_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(_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(_dynticks);
  
 -  RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs 
enabled!!!");
 +  lockdep_assert_irqs_disabled();
-   rdtp = this_cpu_ptr(_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(_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(_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();
+ 

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

[Stephen Rothwell]

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..
--- 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(_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(_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(_dynticks);
  
 -  RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs 
enabled!!!");
 +  lockdep_assert_irqs_disabled();
-   rdtp = this_cpu_ptr(_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(_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(_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();
+ 

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 07:15:40AM -0700, Andy Lutomirski wrote:
> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
>  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
> >(it's already there) [A]
> >   update to rq->curr changing the rq->curr->mm value
> >(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

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 07:15:40AM -0700, Andy Lutomirski wrote:
> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
>  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
> >(it's already there) [A]
> >   update to rq->curr changing the rq->curr->mm value
> >(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

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 04:25:56AM +, Mathieu Desnoyers wrote:
> - On Aug 1, 2017, at 12:03 AM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
> >> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
> >> paul...@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

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 04:25:56AM +, Mathieu Desnoyers wrote:
> - On Aug 1, 2017, at 12:03 AM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
> >> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
> >> paul...@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

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

[Mathieu Desnoyers]

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

> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
>  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
>>(it's already there) [A]
>>   update to rq->curr changing the rq->curr->mm value
>>(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

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

[Mathieu Desnoyers]

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

> On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
>  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
>>(it's already there) [A]
>>   update to rq->curr changing the rq->curr->mm value
>>(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

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

[Andy Lutomirski]

On Tue, Aug 1, 2017 at 7:15 AM, Peter Zijlstra  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.

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

[Andy Lutomirski]

On Tue, Aug 1, 2017 at 7:15 AM, Peter Zijlstra  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.

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

[Andy Lutomirski]

On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
 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
>(it's already there) [A]
>   update to rq->curr changing the rq->curr->mm value
>(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?

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

[Andy Lutomirski]

On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
 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
>(it's already there) [A]
>   update to rq->curr changing the rq->curr->mm value
>(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?

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

[Peter Zijlstra]

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.

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

[Peter Zijlstra]

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.

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

[Mathieu Desnoyers]

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

> On Mon, Jul 31, 2017 at 9:03 PM, Paul E. McKenney
>  wrote:
>> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>>> paul...@linux.vnet.ibm.com
>>> wrote:
>>>
> 
>> Thanx, Paul
>>
>> 
>>
>> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
>> Author: Mathieu Desnoyers 
>> 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
   (it's already there) [A]
  update to rq->curr changing the rq->curr->mm value
   (provided by mm_cpumask updates in switch_mm on x86) [B]
next userspace memory accesses

wrt to:

userspace memory accesses
sys_membarrier
   [C]
  iterate on each cpu's rq->curr, compare their "mm" to current->mm
IPI each CPU that match
   [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(, 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(_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

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

[Mathieu Desnoyers]

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

> On Mon, Jul 31, 2017 at 9:03 PM, Paul E. McKenney
>  wrote:
>> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>>> paul...@linux.vnet.ibm.com
>>> wrote:
>>>
> 
>> Thanx, Paul
>>
>> 
>>
>> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
>> Author: Mathieu Desnoyers 
>> 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
   (it's already there) [A]
  update to rq->curr changing the rq->curr->mm value
   (provided by mm_cpumask updates in switch_mm on x86) [B]
next userspace memory accesses

wrt to:

userspace memory accesses
sys_membarrier
   [C]
  iterate on each cpu's rq->curr, compare their "mm" to current->mm
IPI each CPU that match
   [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(, 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(_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

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

[Peter Zijlstra]

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(, 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(_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.

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

[Peter Zijlstra]

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(, 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(_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.

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

[Andy Lutomirski]

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

> Thanx, Paul
>
> 
>
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers 
> 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(, 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(_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().

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

[Andy Lutomirski]

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

> Thanx, Paul
>
> 
>
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers 
> 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(, 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(_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().

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

[Mathieu Desnoyers]

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

> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>> paul...@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 
> 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 

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

[Mathieu Desnoyers]

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

> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>> paul...@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 
> 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
>  

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
> paul...@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 
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 
CC: Paul E. McKenney 
CC: Boqun Feng 
CC: Andrew Hunter 
CC: Maged Michael 
CC: gro...@google.com
CC: Avi Kivity 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Michael Ellerman 
Signed-off-by: Mathieu Desnoyers 

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

[Paul E. McKenney]

On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
> paul...@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 
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 
CC: Paul E. McKenney 
CC: Boqun Feng 
CC: Andrew Hunter 
CC: Maged Michael 
CC: gro...@google.com
CC: Avi Kivity 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Michael Ellerman 
Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Paul E. McKenney 
Tested-by: Dave Watson 

diff --git a/MAINTAINERS b/MAINTAINERS
index f66488dfdbc9..3b035584272f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8621,7 +8621,7 @@ M:Mathieu Desnoyers 

 M: "Paul 

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

[Mathieu Desnoyers]

- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paul...@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

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

[Mathieu Desnoyers]

- On Jul 31, 2017, at 12:13 PM, Paul E. McKenney paul...@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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Paul E. McKenney]

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

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

[Paul E. McKenney]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Paul E. McKenney]

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

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(>exp_mutex) &&
>   mutex_trylock(>exp_mutex))
>   goto fastpath;
> 
> -- 
> 2.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

[Paul E. McKenney]

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

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(>exp_mutex) &&
>   mutex_trylock(>exp_mutex))
>   goto fastpath;
> 
> -- 
> 2.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell
> 

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

[Stephen Rothwell]

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 
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 
---
 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(>exp_mutex) &&
mutex_trylock(>exp_mutex))
goto fastpath;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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 
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 
---
 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(>exp_mutex) &&
mutex_trylock(>exp_mutex))
goto fastpath;
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

[Paul E. McKenney]

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..
> --- 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(>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(_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.
>*/
> 

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

[Paul E. McKenney]

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..
> --- 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(>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(_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.
>*/
> 

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

[Stephen Rothwell]

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..
--- 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(>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(_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.
   */

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

[Stephen Rothwell]

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..
--- 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(>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(_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.
   */

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc arch/x86/kernel/traps.c
index 8e65d8a9b8db,c5a5231d1d11..
--- 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();
  }
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc arch/x86/kernel/traps.c
index 8e65d8a9b8db,c5a5231d1d11..
--- 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();
  }
  
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc include/linux/rcupdate.h
index 0627a447c589,03a899aabd17..
--- 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..
--- 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..
--- 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(_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


pgpjQtI4u7f0E.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc include/linux/rcupdate.h
index 0627a447c589,03a899aabd17..
--- 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..
--- 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..
--- 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


pgpjQtI4u7f0E.pgp
Description: OpenPGP digital signature

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
> 
> diff --cc kernel/rcu/rcutorture.c
> index 219761db1a46,f59d48597dde..
> --- 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()%10);
> - udelay(rcu_random() & 0x3ff);
> + schedule_timeout_uninterruptible(1 + torture_random()%10);
> + udelay(torture_random() & 0x3ff);
>   if (cur_ops->cb_barrier != NULL &&
> - rcu_random() % (nfakewriters * 8) == 0) {
> + torture_random() % (nfakewriters * 8) == 0) {
>   cur_ops->cb_barrier();
>   } else if (gp_normal == gp_exp) {
> - if (rcu_random() & 0x80)
> + if (torture_random() & 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(, 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();
> - 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 =


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcu/rcutorture.c
index 219761db1a46,f59d48597dde..
--- 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()%10);
-   udelay(rcu_random() & 0x3ff);
+   schedule_timeout_uninterruptible(1 + torture_random()%10);
+   udelay(torture_random() & 0x3ff);
if (cur_ops->cb_barrier != NULL &&
-   rcu_random() % (nfakewriters * 8) == 0) {
+   torture_random() % (nfakewriters * 8) == 0) {
cur_ops->cb_barrier();
} else if (gp_normal == gp_exp) {
-   if (rcu_random() & 0x80)
+   if (torture_random() & 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(, 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();
-   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 =


pgpH3sCBAzTyb.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcu/rcutorture.c
index 219761db1a46,f59d48597dde..
--- 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 =


pgpH3sCBAzTyb.pgp
Description: PGP signature

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
 
 diff --cc kernel/rcu/rcutorture.c
 index 219761db1a46,f59d48597dde..
 --- 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 =


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Zijlstra]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Zijlstra]

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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au


pgpMJOzQESILA.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au


pgpMJOzQESILA.pgp
Description: PGP signature

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
> 
> diff --cc arch/Kconfig
> index 07db929,1c7c9be..000
> --- 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"


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc arch/Kconfig
index 07db929,1c7c9be..000
--- 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"


pgp325J4d8hFH.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc arch/Kconfig
index 07db929,1c7c9be..000
--- 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


pgp325J4d8hFH.pgp
Description: PGP signature

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
 
 diff --cc arch/Kconfig
 index 07db929,1c7c9be..000
 --- 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


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
> 
> diff --cc kernel/rcutree.h
> index 1224d4c,c2a3e7d..000
> --- 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;
>   
>   /*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
> 
> diff --cc kernel/rcutree_plugin.h
> index c1961ae,c3e3fc4..000
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@@ -25,7 -25,7 +25,8 @@@
>*/
>   
>   #include 
>  +#include 
> + #include 
>   
>   #define RCU_KTHREAD_PRIO 1
>   


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree.h
index 1224d4c,c2a3e7d..000
--- 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;
  
  /*


pgpB7WC3i9BNf.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree_plugin.h
index c1961ae,c3e3fc4..000
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@@ -25,7 -25,7 +25,8 @@@
   */
  
  #include 
 +#include 
+ #include 
  
  #define RCU_KTHREAD_PRIO 1
  


pgp7wIABzTgUz.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree_plugin.h
index c1961ae,c3e3fc4..000
--- 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
  


pgp7wIABzTgUz.pgp
Description: PGP signature

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

[Stephen Rothwell]

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 Rothwells...@canb.auug.org.au

diff --cc kernel/rcutree.h
index 1224d4c,c2a3e7d..000
--- 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;
  
  /*


pgpB7WC3i9BNf.pgp
Description: PGP signature

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
 
 diff --cc kernel/rcutree_plugin.h
 index c1961ae,c3e3fc4..000
 --- 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
   


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Paul E. McKenney]

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 Rothwells...@canb.auug.org.au
 
 diff --cc kernel/rcutree.h
 index 1224d4c,c2a3e7d..000
 --- 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;
   
   /*


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/