Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-24 Thread Boqun Feng 
On Tue, May 24, 2016 at 11:06:52AM -0700, Paul E. McKenney wrote:
> On Mon, May 23, 2016 at 12:35:35PM +0800, Boqun Feng wrote:
> > On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> > > On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > > > Hi Paul,
> > > > 
> > > > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > > > Greetings,
> > > > > > 
> > > > > > 0day kernel testing robot got the below dmesg and the first bad 
> > > > > > commit is
> > > > > > 
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > > > master
> > > > > > 
> > > > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > > > Author: Paul E. McKenney 
> > > > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > > > Commit: Paul E. McKenney 
> > > > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > > > 
> > > > > > rcutorture: Add RCU grace-period performance tests
> > > > > > 
> > > > > > This commit adds a new rcuperf module that carries out simple 
> > > > > > performance
> > > > > > tests of RCU grace periods.
> > > > > > 
> > > > > > Signed-off-by: Paul E. McKenney 
> > > > > 
> > > > > ???
> > > > > 
> > > > > This commit adds a default-n performance-test module.  I don't believe
> > > > 
> > > > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > > > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > > > 
> > > > > that this would result in boot failures.  False bisection?
> > > > > 
> > > > 
> > > > The code triggering the warning is:
> > > > 
> > > > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > > > 
> > > > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > > > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > > > for rcutorture is false). That's why the warnning was triggered.
> > > > 
> > > > It happened in the boot progress because rcu_perf_writer threads were
> > > > created and ran via module init function rcu_perf_init().
> > > > 
> > > > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> > > 
> > > Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> > > WARN_ON() to soething that results in torture-test failure but does
> > > not cause 0day to complain.  Or...
> > > 
> > 
> > So I think a better is we
> > 
> > 1.  set the default value to false (to align with rcutorture)
> > 
> > and
> > 
> > 2.  downgrade the WARN_ON() to torture-test failures, because those
> > are not kernel bugs.
> > 
> > Here is a patch for further discussion:
> 
> This patch looks good to me, given a little editing of the commit log.
> (See below for error string suggestion.)
> 

Those are better (shorter and more accurate), thank you! I will send out
a standalone patch with the modification.

Regards,
Boqun

> Other thoughts?
> 
>   Thanx, Paul
> 
> > ->8
> > Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning
> > 
> > 0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:
> > 
> > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > 
> > , which turned out to be caused by the default value of gp_exp.
> > 
> > However, the reason of the warning is only mis-setting, which should be
> > handled inside rcuperf module rather than treated as a kernel warning.
> > 
> > Therefore this patch moves the WARN_ON from rcu_perf_writer() and
> > handles those checkings in rcu_perf_init(), which could also save the
> > checkings for each writer.
> > 
> > Moreover, this patch changes the default value of gp_exp to 1) align
> > with rcutorture tests and 2) make the default setting work for all RCU
> > implementations by default.
> > 
> > Signed-off-by: Boqun Feng 
> > Fixes: 
> > http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
> > ---
> >  kernel/rcu/rcuperf.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index 3cee0d8393ed..1dc2bd1de4b6 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
> > ");
> >  #define VERBOSE_PERFOUT_ERRSTRING(s) \
> > do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
> > while (0)
> > 
> > -torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
> > +torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
> >  torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
> >  torture_param(int, nreaders, -1, "Number of RCU reader threads");
> >  torture_param(int, nwriters, -1, "Number of RCU updater threads");
> > @@ -363,8 +363,6 @@

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-24 Thread Boqun Feng 
On Tue, May 24, 2016 at 11:06:52AM -0700, Paul E. McKenney wrote:
> On Mon, May 23, 2016 at 12:35:35PM +0800, Boqun Feng wrote:
> > On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> > > On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > > > Hi Paul,
> > > > 
> > > > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > > > Greetings,
> > > > > > 
> > > > > > 0day kernel testing robot got the below dmesg and the first bad 
> > > > > > commit is
> > > > > > 
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > > > master
> > > > > > 
> > > > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > > > Author: Paul E. McKenney 
> > > > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > > > Commit: Paul E. McKenney 
> > > > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > > > 
> > > > > > rcutorture: Add RCU grace-period performance tests
> > > > > > 
> > > > > > This commit adds a new rcuperf module that carries out simple 
> > > > > > performance
> > > > > > tests of RCU grace periods.
> > > > > > 
> > > > > > Signed-off-by: Paul E. McKenney 
> > > > > 
> > > > > ???
> > > > > 
> > > > > This commit adds a default-n performance-test module.  I don't believe
> > > > 
> > > > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > > > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > > > 
> > > > > that this would result in boot failures.  False bisection?
> > > > > 
> > > > 
> > > > The code triggering the warning is:
> > > > 
> > > > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > > > 
> > > > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > > > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > > > for rcutorture is false). That's why the warnning was triggered.
> > > > 
> > > > It happened in the boot progress because rcu_perf_writer threads were
> > > > created and ran via module init function rcu_perf_init().
> > > > 
> > > > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> > > 
> > > Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> > > WARN_ON() to soething that results in torture-test failure but does
> > > not cause 0day to complain.  Or...
> > > 
> > 
> > So I think a better is we
> > 
> > 1.  set the default value to false (to align with rcutorture)
> > 
> > and
> > 
> > 2.  downgrade the WARN_ON() to torture-test failures, because those
> > are not kernel bugs.
> > 
> > Here is a patch for further discussion:
> 
> This patch looks good to me, given a little editing of the commit log.
> (See below for error string suggestion.)
> 

Those are better (shorter and more accurate), thank you! I will send out
a standalone patch with the modification.

Regards,
Boqun

> Other thoughts?
> 
>   Thanx, Paul
> 
> > ->8
> > Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning
> > 
> > 0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:
> > 
> > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > 
> > , which turned out to be caused by the default value of gp_exp.
> > 
> > However, the reason of the warning is only mis-setting, which should be
> > handled inside rcuperf module rather than treated as a kernel warning.
> > 
> > Therefore this patch moves the WARN_ON from rcu_perf_writer() and
> > handles those checkings in rcu_perf_init(), which could also save the
> > checkings for each writer.
> > 
> > Moreover, this patch changes the default value of gp_exp to 1) align
> > with rcutorture tests and 2) make the default setting work for all RCU
> > implementations by default.
> > 
> > Signed-off-by: Boqun Feng 
> > Fixes: 
> > http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
> > ---
> >  kernel/rcu/rcuperf.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index 3cee0d8393ed..1dc2bd1de4b6 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
> > ");
> >  #define VERBOSE_PERFOUT_ERRSTRING(s) \
> > do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
> > while (0)
> > 
> > -torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
> > +torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
> >  torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
> >  torture_param(int, nreaders, -1, "Number of RCU reader threads");
> >  torture_param(int, nwriters, -1, "Number of RCU updater threads");
> > @@ -363,8 +363,6 @@ rcu_perf_writer(void *arg)
> > u64 *wdpp = writer_durations[me];
> > 
> > VERBOSE_PERFOUT_STRING("rcu_perf_writer task

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-24 Thread Paul E. McKenney 
On Mon, May 23, 2016 at 12:35:35PM +0800, Boqun Feng wrote:
> On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> > On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > > Hi Paul,
> > > 
> > > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > > Greetings,
> > > > > 
> > > > > 0day kernel testing robot got the below dmesg and the first bad 
> > > > > commit is
> > > > > 
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > > master
> > > > > 
> > > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > > Author: Paul E. McKenney 
> > > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > > Commit: Paul E. McKenney 
> > > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > > 
> > > > > rcutorture: Add RCU grace-period performance tests
> > > > > 
> > > > > This commit adds a new rcuperf module that carries out simple 
> > > > > performance
> > > > > tests of RCU grace periods.
> > > > > 
> > > > > Signed-off-by: Paul E. McKenney 
> > > > 
> > > > ???
> > > > 
> > > > This commit adds a default-n performance-test module.  I don't believe
> > > 
> > > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > > 
> > > > that this would result in boot failures.  False bisection?
> > > > 
> > > 
> > > The code triggering the warning is:
> > > 
> > >   WARN_ON(rcu_gp_is_normal() && gp_exp);
> > > 
> > > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > > for rcutorture is false). That's why the warnning was triggered.
> > > 
> > > It happened in the boot progress because rcu_perf_writer threads were
> > > created and ran via module init function rcu_perf_init().
> > > 
> > > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> > 
> > Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> > WARN_ON() to soething that results in torture-test failure but does
> > not cause 0day to complain.  Or...
> > 
> 
> So I think a better is we
> 
> 1.set the default value to false (to align with rcutorture)
> 
> and
> 
> 2.downgrade the WARN_ON() to torture-test failures, because those
>   are not kernel bugs.
> 
> Here is a patch for further discussion:

This patch looks good to me, given a little editing of the commit log.
(See below for error string suggestion.)

Other thoughts?

Thanx, Paul

> ->8
> Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning
> 
> 0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:
> 
>   WARN_ON(rcu_gp_is_normal() && gp_exp);
> 
> , which turned out to be caused by the default value of gp_exp.
> 
> However, the reason of the warning is only mis-setting, which should be
> handled inside rcuperf module rather than treated as a kernel warning.
> 
> Therefore this patch moves the WARN_ON from rcu_perf_writer() and
> handles those checkings in rcu_perf_init(), which could also save the
> checkings for each writer.
> 
> Moreover, this patch changes the default value of gp_exp to 1) align
> with rcutorture tests and 2) make the default setting work for all RCU
> implementations by default.
> 
> Signed-off-by: Boqun Feng 
> Fixes: 
> http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
> ---
>  kernel/rcu/rcuperf.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index 3cee0d8393ed..1dc2bd1de4b6 100644
> --- a/kernel/rcu/rcuperf.c
> +++ b/kernel/rcu/rcuperf.c
> @@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
> ");
>  #define VERBOSE_PERFOUT_ERRSTRING(s) \
>   do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
> while (0)
> 
> -torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
> +torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
>  torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
>  torture_param(int, nreaders, -1, "Number of RCU reader threads");
>  torture_param(int, nwriters, -1, "Number of RCU updater threads");
> @@ -363,8 +363,6 @@ rcu_perf_writer(void *arg)
>   u64 *wdpp = writer_durations[me];
> 
>   VERBOSE_PERFOUT_STRING("rcu_perf_writer task started");
> - WARN_ON(rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp);
> - WARN_ON(rcu_gp_is_normal() && gp_exp);
>   WARN_ON(!wdpp);
>   set_cpus_allowed_ptr(current, cpumask_of(me % nr_cpu_ids));
>   sp.sched_priority = 1;
> @@ -631,6 +629,16 @@ rcu_perf_init(void)
>

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-24 Thread Paul E. McKenney 
On Mon, May 23, 2016 at 12:35:35PM +0800, Boqun Feng wrote:
> On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> > On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > > Hi Paul,
> > > 
> > > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > > Greetings,
> > > > > 
> > > > > 0day kernel testing robot got the below dmesg and the first bad 
> > > > > commit is
> > > > > 
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > > master
> > > > > 
> > > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > > Author: Paul E. McKenney 
> > > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > > Commit: Paul E. McKenney 
> > > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > > 
> > > > > rcutorture: Add RCU grace-period performance tests
> > > > > 
> > > > > This commit adds a new rcuperf module that carries out simple 
> > > > > performance
> > > > > tests of RCU grace periods.
> > > > > 
> > > > > Signed-off-by: Paul E. McKenney 
> > > > 
> > > > ???
> > > > 
> > > > This commit adds a default-n performance-test module.  I don't believe
> > > 
> > > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > > 
> > > > that this would result in boot failures.  False bisection?
> > > > 
> > > 
> > > The code triggering the warning is:
> > > 
> > >   WARN_ON(rcu_gp_is_normal() && gp_exp);
> > > 
> > > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > > for rcutorture is false). That's why the warnning was triggered.
> > > 
> > > It happened in the boot progress because rcu_perf_writer threads were
> > > created and ran via module init function rcu_perf_init().
> > > 
> > > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> > 
> > Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> > WARN_ON() to soething that results in torture-test failure but does
> > not cause 0day to complain.  Or...
> > 
> 
> So I think a better is we
> 
> 1.set the default value to false (to align with rcutorture)
> 
> and
> 
> 2.downgrade the WARN_ON() to torture-test failures, because those
>   are not kernel bugs.
> 
> Here is a patch for further discussion:

This patch looks good to me, given a little editing of the commit log.
(See below for error string suggestion.)

Other thoughts?

Thanx, Paul

> ->8
> Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning
> 
> 0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:
> 
>   WARN_ON(rcu_gp_is_normal() && gp_exp);
> 
> , which turned out to be caused by the default value of gp_exp.
> 
> However, the reason of the warning is only mis-setting, which should be
> handled inside rcuperf module rather than treated as a kernel warning.
> 
> Therefore this patch moves the WARN_ON from rcu_perf_writer() and
> handles those checkings in rcu_perf_init(), which could also save the
> checkings for each writer.
> 
> Moreover, this patch changes the default value of gp_exp to 1) align
> with rcutorture tests and 2) make the default setting work for all RCU
> implementations by default.
> 
> Signed-off-by: Boqun Feng 
> Fixes: 
> http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
> ---
>  kernel/rcu/rcuperf.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index 3cee0d8393ed..1dc2bd1de4b6 100644
> --- a/kernel/rcu/rcuperf.c
> +++ b/kernel/rcu/rcuperf.c
> @@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
> ");
>  #define VERBOSE_PERFOUT_ERRSTRING(s) \
>   do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
> while (0)
> 
> -torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
> +torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
>  torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
>  torture_param(int, nreaders, -1, "Number of RCU reader threads");
>  torture_param(int, nwriters, -1, "Number of RCU updater threads");
> @@ -363,8 +363,6 @@ rcu_perf_writer(void *arg)
>   u64 *wdpp = writer_durations[me];
> 
>   VERBOSE_PERFOUT_STRING("rcu_perf_writer task started");
> - WARN_ON(rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp);
> - WARN_ON(rcu_gp_is_normal() && gp_exp);
>   WARN_ON(!wdpp);
>   set_cpus_allowed_ptr(current, cpumask_of(me % nr_cpu_ids));
>   sp.sched_priority = 1;
> @@ -631,6 +629,16 @@ rcu_perf_init(void)
>   firsterr = -ENOMEM;
>   goto unwind;
>   }
> + if (rcu_gp_is_expedited() && !rcu_gp_is_normal() &&

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Boqun Feng 
On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > Hi Paul,
> > 
> > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > Greetings,
> > > > 
> > > > 0day kernel testing robot got the below dmesg and the first bad commit 
> > > > is
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > master
> > > > 
> > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > Author: Paul E. McKenney 
> > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > Commit: Paul E. McKenney 
> > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > 
> > > > rcutorture: Add RCU grace-period performance tests
> > > > 
> > > > This commit adds a new rcuperf module that carries out simple 
> > > > performance
> > > > tests of RCU grace periods.
> > > > 
> > > > Signed-off-by: Paul E. McKenney 
> > > 
> > > ???
> > > 
> > > This commit adds a default-n performance-test module.  I don't believe
> > 
> > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > 
> > > that this would result in boot failures.  False bisection?
> > > 
> > 
> > The code triggering the warning is:
> > 
> > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > 
> > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > for rcutorture is false). That's why the warnning was triggered.
> > 
> > It happened in the boot progress because rcu_perf_writer threads were
> > created and ran via module init function rcu_perf_init().
> > 
> > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> 
> Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> WARN_ON() to soething that results in torture-test failure but does
> not cause 0day to complain.  Or...
> 

So I think a better is we

1.  set the default value to false (to align with rcutorture)

and

2.  downgrade the WARN_ON() to torture-test failures, because those
are not kernel bugs.

Here is a patch for further discussion:

->8
Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning

0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:

WARN_ON(rcu_gp_is_normal() && gp_exp);

, which turned out to be caused by the default value of gp_exp.

However, the reason of the warning is only mis-setting, which should be
handled inside rcuperf module rather than treated as a kernel warning.

Therefore this patch moves the WARN_ON from rcu_perf_writer() and
handles those checkings in rcu_perf_init(), which could also save the
checkings for each writer.

Moreover, this patch changes the default value of gp_exp to 1) align
with rcutorture tests and 2) make the default setting work for all RCU
implementations by default.

Signed-off-by: Boqun Feng 
Fixes: http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
---
 kernel/rcu/rcuperf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 3cee0d8393ed..1dc2bd1de4b6 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
");
 #define VERBOSE_PERFOUT_ERRSTRING(s) \
do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
while (0)
 
-torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
+torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
 torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
 torture_param(int, nreaders, -1, "Number of RCU reader threads");
 torture_param(int, nwriters, -1, "Number of RCU updater threads");
@@ -363,8 +363,6 @@ rcu_perf_writer(void *arg)
u64 *wdpp = writer_durations[me];
 
VERBOSE_PERFOUT_STRING("rcu_perf_writer task started");
-   WARN_ON(rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp);
-   WARN_ON(rcu_gp_is_normal() && gp_exp);
WARN_ON(!wdpp);
set_cpus_allowed_ptr(current, cpumask_of(me % nr_cpu_ids));
sp.sched_priority = 1;
@@ -631,6 +629,16 @@ rcu_perf_init(void)
firsterr = -ENOMEM;
goto unwind;
}
+   if (rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp) {
+   VERBOSE_PERFOUT_ERRSTRING("try to measure normal grace periods 
when all the grace periods are expedited");
+   firsterr = -EINVAL;
+   goto unwind;
+   }
+   if (rcu_gp_is_normal() && gp_exp) {
+   VERBOSE_PERFOUT_ERRSTRING("try to measure expedited grace 
periods

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Boqun Feng 
On Sun, May 22, 2016 at 08:28:06AM -0700, Paul E. McKenney wrote:
> On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> > Hi Paul,
> > 
> > On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > > Greetings,
> > > > 
> > > > 0day kernel testing robot got the below dmesg and the first bad commit 
> > > > is
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > > > master
> > > > 
> > > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > > Author: Paul E. McKenney 
> > > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > > Commit: Paul E. McKenney 
> > > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > > 
> > > > rcutorture: Add RCU grace-period performance tests
> > > > 
> > > > This commit adds a new rcuperf module that carries out simple 
> > > > performance
> > > > tests of RCU grace periods.
> > > > 
> > > > Signed-off-by: Paul E. McKenney 
> > > 
> > > ???
> > > 
> > > This commit adds a default-n performance-test module.  I don't believe
> > 
> > I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> > CONFIG_RCU_PERF_TEST=y configuration ;-)
> > 
> > > that this would result in boot failures.  False bisection?
> > > 
> > 
> > The code triggering the warning is:
> > 
> > WARN_ON(rcu_gp_is_normal() && gp_exp);
> > 
> > , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> > the default value of gp_exp for *rcuperf* is also true (whereas the one
> > for rcutorture is false). That's why the warnning was triggered.
> > 
> > It happened in the boot progress because rcu_perf_writer threads were
> > created and ran via module init function rcu_perf_init().
> > 
> > Maybe we'd better change the defaut value of gp_exp for rcuperf?
> 
> Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
> WARN_ON() to soething that results in torture-test failure but does
> not cause 0day to complain.  Or...
> 

So I think a better is we

1.  set the default value to false (to align with rcutorture)

and

2.  downgrade the WARN_ON() to torture-test failures, because those
are not kernel bugs.

Here is a patch for further discussion:

->8
Subject: [PATCH] rcuperf: Don't treat gp_exp mis-setting as a kernel warning

0day found a boot warning triggered in rcu_perf_writer() on !SMP kernel:

WARN_ON(rcu_gp_is_normal() && gp_exp);

, which turned out to be caused by the default value of gp_exp.

However, the reason of the warning is only mis-setting, which should be
handled inside rcuperf module rather than treated as a kernel warning.

Therefore this patch moves the WARN_ON from rcu_perf_writer() and
handles those checkings in rcu_perf_init(), which could also save the
checkings for each writer.

Moreover, this patch changes the default value of gp_exp to 1) align
with rcutorture tests and 2) make the default setting work for all RCU
implementations by default.

Signed-off-by: Boqun Feng 
Fixes: http://lkml.kernel.org/r/57411b10.mfvg0+agcrmxgtcj%fengguang...@intel.com
---
 kernel/rcu/rcuperf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 3cee0d8393ed..1dc2bd1de4b6 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -58,7 +58,7 @@ MODULE_AUTHOR("Paul E. McKenney 
");
 #define VERBOSE_PERFOUT_ERRSTRING(s) \
do { if (verbose) pr_alert("%s" PERF_FLAG "!!! %s\n", perf_type, s); } 
while (0)
 
-torture_param(bool, gp_exp, true, "Use expedited GP wait primitives");
+torture_param(bool, gp_exp, false, "Use expedited GP wait primitives");
 torture_param(int, holdoff, 10, "Holdoff time before test start (s)");
 torture_param(int, nreaders, -1, "Number of RCU reader threads");
 torture_param(int, nwriters, -1, "Number of RCU updater threads");
@@ -363,8 +363,6 @@ rcu_perf_writer(void *arg)
u64 *wdpp = writer_durations[me];
 
VERBOSE_PERFOUT_STRING("rcu_perf_writer task started");
-   WARN_ON(rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp);
-   WARN_ON(rcu_gp_is_normal() && gp_exp);
WARN_ON(!wdpp);
set_cpus_allowed_ptr(current, cpumask_of(me % nr_cpu_ids));
sp.sched_priority = 1;
@@ -631,6 +629,16 @@ rcu_perf_init(void)
firsterr = -ENOMEM;
goto unwind;
}
+   if (rcu_gp_is_expedited() && !rcu_gp_is_normal() && !gp_exp) {
+   VERBOSE_PERFOUT_ERRSTRING("try to measure normal grace periods 
when all the grace periods are expedited");
+   firsterr = -EINVAL;
+   goto unwind;
+   }
+   if (rcu_gp_is_normal() && gp_exp) {
+   VERBOSE_PERFOUT_ERRSTRING("try to measure expedited grace 
periods when all the expedited ones fall back to the normal ones");
+   firsterr = -EINVAL;
+   goto unwind;
+   }

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Paul E. McKenney 
On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> Hi Paul,
> 
> On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > Greetings,
> > > 
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > 
> > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > Author: Paul E. McKenney 
> > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > Commit: Paul E. McKenney 
> > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > 
> > > rcutorture: Add RCU grace-period performance tests
> > > 
> > > This commit adds a new rcuperf module that carries out simple 
> > > performance
> > > tests of RCU grace periods.
> > > 
> > > Signed-off-by: Paul E. McKenney 
> > 
> > ???
> > 
> > This commit adds a default-n performance-test module.  I don't believe
> 
> I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> CONFIG_RCU_PERF_TEST=y configuration ;-)
> 
> > that this would result in boot failures.  False bisection?
> > 
> 
> The code triggering the warning is:
> 
>   WARN_ON(rcu_gp_is_normal() && gp_exp);
> 
> , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> the default value of gp_exp for *rcuperf* is also true (whereas the one
> for rcutorture is false). That's why the warnning was triggered.
> 
> It happened in the boot progress because rcu_perf_writer threads were
> created and ran via module init function rcu_perf_init().
> 
> Maybe we'd better change the defaut value of gp_exp for rcuperf?

Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
WARN_ON() to soething that results in torture-test failure but does
not cause 0day to complain.  Or...

Thanx, Paul

> Regards,
> Boqun
> 
> 
> > Thanx, Paul
> > 
> > > +---++++
> > > |   | 291783b8ad | 
> > > 8704baab9b | ce82e4a05f |
> > > +---++++
> > > | boot_successes| 57 | 0  
> > > | 0  |
> > > | boot_failures | 6  | 22 
> > > | 13 |
> > > | BUG:unable_to_handle_kernel   | 6  | 22 
> > > ||
> > > | Oops  | 6  | 22 
> > > ||
> > > | EIP_is_at_get_perf_callchain  | 6  |
> > > ||
> > > | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22 
> > > ||
> > > | backtrace:acpi_get_cpuid  | 6  | 22 
> > > | 13 |
> > > | backtrace:early_init_pdc  | 6  | 22 
> > > | 13 |
> > > | backtrace:acpi_early_processor_set_pdc| 6  | 22 
> > > | 13 |
> > > | backtrace:acpi_init   | 6  | 22 
> > > | 13 |
> > > | backtrace:kernel_init_freeable| 6  | 22 
> > > | 13 |
> > > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |
> > > ||
> > > | backtrace:vfs_fstatat | 2  |
> > > ||
> > > | backtrace:SyS_fstatat64   | 2  |
> > > ||
> > > | backtrace:SYSC_socketcall | 2  |
> > > ||
> > > | backtrace:SyS_socketcall  | 2  | 0  
> > > | 6  |
> > > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22 
> > > | 13 |
> > > | BUG:spinlock_bad_magic_on_CPU | 0  | 22 
> > > ||
> > > | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22 
> > > ||
> > > | EIP_is_at__wake_up_common | 0  | 22 
> > > ||
> > > | backtrace:rcu_perf_writer | 0  | 22 
> > > | 13 |
> > > | backtrace:sock_setsockopt | 0  | 0  
> > > | 6  |
> > > | backtrace:rht_deferred_worker | 0  | 0  
> > > | 3  |
> > >

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Paul E. McKenney 
On Sun, May 22, 2016 at 02:26:49PM +0800, Boqun Feng wrote:
> Hi Paul,
> 
> On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> > On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > > Greetings,
> > > 
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > 
> > > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > > Author: Paul E. McKenney 
> > > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > > Commit: Paul E. McKenney 
> > > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > > 
> > > rcutorture: Add RCU grace-period performance tests
> > > 
> > > This commit adds a new rcuperf module that carries out simple 
> > > performance
> > > tests of RCU grace periods.
> > > 
> > > Signed-off-by: Paul E. McKenney 
> > 
> > ???
> > 
> > This commit adds a default-n performance-test module.  I don't believe
> 
> I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
> CONFIG_RCU_PERF_TEST=y configuration ;-)
> 
> > that this would result in boot failures.  False bisection?
> > 
> 
> The code triggering the warning is:
> 
>   WARN_ON(rcu_gp_is_normal() && gp_exp);
> 
> , so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
> the default value of gp_exp for *rcuperf* is also true (whereas the one
> for rcutorture is false). That's why the warnning was triggered.
> 
> It happened in the boot progress because rcu_perf_writer threads were
> created and ran via module init function rcu_perf_init().
> 
> Maybe we'd better change the defaut value of gp_exp for rcuperf?

Or make the default depend on CONFIG_TINY_RCU.  Or downgrade the
WARN_ON() to soething that results in torture-test failure but does
not cause 0day to complain.  Or...

Thanx, Paul

> Regards,
> Boqun
> 
> 
> > Thanx, Paul
> > 
> > > +---++++
> > > |   | 291783b8ad | 
> > > 8704baab9b | ce82e4a05f |
> > > +---++++
> > > | boot_successes| 57 | 0  
> > > | 0  |
> > > | boot_failures | 6  | 22 
> > > | 13 |
> > > | BUG:unable_to_handle_kernel   | 6  | 22 
> > > ||
> > > | Oops  | 6  | 22 
> > > ||
> > > | EIP_is_at_get_perf_callchain  | 6  |
> > > ||
> > > | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22 
> > > ||
> > > | backtrace:acpi_get_cpuid  | 6  | 22 
> > > | 13 |
> > > | backtrace:early_init_pdc  | 6  | 22 
> > > | 13 |
> > > | backtrace:acpi_early_processor_set_pdc| 6  | 22 
> > > | 13 |
> > > | backtrace:acpi_init   | 6  | 22 
> > > | 13 |
> > > | backtrace:kernel_init_freeable| 6  | 22 
> > > | 13 |
> > > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |
> > > ||
> > > | backtrace:vfs_fstatat | 2  |
> > > ||
> > > | backtrace:SyS_fstatat64   | 2  |
> > > ||
> > > | backtrace:SYSC_socketcall | 2  |
> > > ||
> > > | backtrace:SyS_socketcall  | 2  | 0  
> > > | 6  |
> > > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22 
> > > | 13 |
> > > | BUG:spinlock_bad_magic_on_CPU | 0  | 22 
> > > ||
> > > | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22 
> > > ||
> > > | EIP_is_at__wake_up_common | 0  | 22 
> > > ||
> > > | backtrace:rcu_perf_writer | 0  | 22 
> > > | 13 |
> > > | backtrace:sock_setsockopt | 0  | 0  
> > > | 6  |
> > > | backtrace:rht_deferred_worker | 0  | 0  
> > > | 3  |
> > > +---++++
> > > 
> > > [

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Boqun Feng 
Hi Paul,

On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > Greetings,
> > 
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > 
> > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > Author: Paul E. McKenney 
> > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > Commit: Paul E. McKenney 
> > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > 
> > rcutorture: Add RCU grace-period performance tests
> > 
> > This commit adds a new rcuperf module that carries out simple 
> > performance
> > tests of RCU grace periods.
> > 
> > Signed-off-by: Paul E. McKenney 
> 
> ???
> 
> This commit adds a default-n performance-test module.  I don't believe

I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
CONFIG_RCU_PERF_TEST=y configuration ;-)

> that this would result in boot failures.  False bisection?
> 

The code triggering the warning is:

WARN_ON(rcu_gp_is_normal() && gp_exp);

, so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
the default value of gp_exp for *rcuperf* is also true (whereas the one
for rcutorture is false). That's why the warnning was triggered.

It happened in the boot progress because rcu_perf_writer threads were
created and ran via module init function rcu_perf_init().

Maybe we'd better change the defaut value of gp_exp for rcuperf?

Regards,
Boqun


>   Thanx, Paul
> 
> > +---++++
> > |   | 291783b8ad | 
> > 8704baab9b | ce82e4a05f |
> > +---++++
> > | boot_successes| 57 | 0
> >   | 0  |
> > | boot_failures | 6  | 22   
> >   | 13 |
> > | BUG:unable_to_handle_kernel   | 6  | 22   
> >   ||
> > | Oops  | 6  | 22   
> >   ||
> > | EIP_is_at_get_perf_callchain  | 6  |  
> >   ||
> > | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22   
> >   ||
> > | backtrace:acpi_get_cpuid  | 6  | 22   
> >   | 13 |
> > | backtrace:early_init_pdc  | 6  | 22   
> >   | 13 |
> > | backtrace:acpi_early_processor_set_pdc| 6  | 22   
> >   | 13 |
> > | backtrace:acpi_init   | 6  | 22   
> >   | 13 |
> > | backtrace:kernel_init_freeable| 6  | 22   
> >   | 13 |
> > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |  
> >   ||
> > | backtrace:vfs_fstatat | 2  |  
> >   ||
> > | backtrace:SyS_fstatat64   | 2  |  
> >   ||
> > | backtrace:SYSC_socketcall | 2  |  
> >   ||
> > | backtrace:SyS_socketcall  | 2  | 0
> >   | 6  |
> > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22   
> >   | 13 |
> > | BUG:spinlock_bad_magic_on_CPU | 0  | 22   
> >   ||
> > | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22   
> >   ||
> > | EIP_is_at__wake_up_common | 0  | 22   
> >   ||
> > | backtrace:rcu_perf_writer | 0  | 22   
> >   | 13 |
> > | backtrace:sock_setsockopt | 0  | 0
> >   | 6  |
> > | backtrace:rht_deferred_worker | 0  | 0
> >   | 3  |
> > +---++++
> > 
> > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 4.6.0-rc1-5-g8704baa #3
> > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 4.6.0-rc1-5-g8704baa #3
> > [1.062485]  
> > [1.062485]   cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc 
> > c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac 
> > cf03bcac
> > 
> > [1.064620]  c157aa41
> > [1.064620]

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-22 Thread Boqun Feng 
Hi Paul,

On Sat, May 21, 2016 at 10:24:22PM -0700, Paul E. McKenney wrote:
> On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> > Greetings,
> > 
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > 
> > commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> > Author: Paul E. McKenney 
> > AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> > Commit: Paul E. McKenney 
> > CommitDate: Thu Mar 31 13:37:38 2016 -0700
> > 
> > rcutorture: Add RCU grace-period performance tests
> > 
> > This commit adds a new rcuperf module that carries out simple 
> > performance
> > tests of RCU grace periods.
> > 
> > Signed-off-by: Paul E. McKenney 
> 
> ???
> 
> This commit adds a default-n performance-test module.  I don't believe

I think the robot was using a !SMP && CONFIG_TORTURE_TEST=y &&
CONFIG_RCU_PERF_TEST=y configuration ;-)

> that this would result in boot failures.  False bisection?
> 

The code triggering the warning is:

WARN_ON(rcu_gp_is_normal() && gp_exp);

, so rcu_gp_is_normal() is true because we are using TINY RCU, moreover
the default value of gp_exp for *rcuperf* is also true (whereas the one
for rcutorture is false). That's why the warnning was triggered.

It happened in the boot progress because rcu_perf_writer threads were
created and ran via module init function rcu_perf_init().

Maybe we'd better change the defaut value of gp_exp for rcuperf?

Regards,
Boqun


>   Thanx, Paul
> 
> > +---++++
> > |   | 291783b8ad | 
> > 8704baab9b | ce82e4a05f |
> > +---++++
> > | boot_successes| 57 | 0
> >   | 0  |
> > | boot_failures | 6  | 22   
> >   | 13 |
> > | BUG:unable_to_handle_kernel   | 6  | 22   
> >   ||
> > | Oops  | 6  | 22   
> >   ||
> > | EIP_is_at_get_perf_callchain  | 6  |  
> >   ||
> > | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22   
> >   ||
> > | backtrace:acpi_get_cpuid  | 6  | 22   
> >   | 13 |
> > | backtrace:early_init_pdc  | 6  | 22   
> >   | 13 |
> > | backtrace:acpi_early_processor_set_pdc| 6  | 22   
> >   | 13 |
> > | backtrace:acpi_init   | 6  | 22   
> >   | 13 |
> > | backtrace:kernel_init_freeable| 6  | 22   
> >   | 13 |
> > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |  
> >   ||
> > | backtrace:vfs_fstatat | 2  |  
> >   ||
> > | backtrace:SyS_fstatat64   | 2  |  
> >   ||
> > | backtrace:SYSC_socketcall | 2  |  
> >   ||
> > | backtrace:SyS_socketcall  | 2  | 0
> >   | 6  |
> > | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22   
> >   | 13 |
> > | BUG:spinlock_bad_magic_on_CPU | 0  | 22   
> >   ||
> > | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22   
> >   ||
> > | EIP_is_at__wake_up_common | 0  | 22   
> >   ||
> > | backtrace:rcu_perf_writer | 0  | 22   
> >   | 13 |
> > | backtrace:sock_setsockopt | 0  | 0
> >   | 6  |
> > | backtrace:rht_deferred_worker | 0  | 0
> >   | 3  |
> > +---++++
> > 
> > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 4.6.0-rc1-5-g8704baa #3
> > [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 4.6.0-rc1-5-g8704baa #3
> > [1.062485]  
> > [1.062485]   cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc 
> > c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac 
> > cf03bcac
> > 
> > [1.064620]  c157aa41
> > [1.064620]  c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 
> > c1ed4958 0202 0202

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-21 Thread Paul E. McKenney 
On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> Author: Paul E. McKenney 
> AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> Commit: Paul E. McKenney 
> CommitDate: Thu Mar 31 13:37:38 2016 -0700
> 
> rcutorture: Add RCU grace-period performance tests
> 
> This commit adds a new rcuperf module that carries out simple performance
> tests of RCU grace periods.
> 
> Signed-off-by: Paul E. McKenney 

???

This commit adds a default-n performance-test module.  I don't believe
that this would result in boot failures.  False bisection?

Thanx, Paul

> +---++++
> |   | 291783b8ad | 
> 8704baab9b | ce82e4a05f |
> +---++++
> | boot_successes| 57 | 0  
> | 0  |
> | boot_failures | 6  | 22 
> | 13 |
> | BUG:unable_to_handle_kernel   | 6  | 22 
> ||
> | Oops  | 6  | 22 
> ||
> | EIP_is_at_get_perf_callchain  | 6  |
> ||
> | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22 
> ||
> | backtrace:acpi_get_cpuid  | 6  | 22 
> | 13 |
> | backtrace:early_init_pdc  | 6  | 22 
> | 13 |
> | backtrace:acpi_early_processor_set_pdc| 6  | 22 
> | 13 |
> | backtrace:acpi_init   | 6  | 22 
> | 13 |
> | backtrace:kernel_init_freeable| 6  | 22 
> | 13 |
> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |
> ||
> | backtrace:vfs_fstatat | 2  |
> ||
> | backtrace:SyS_fstatat64   | 2  |
> ||
> | backtrace:SYSC_socketcall | 2  |
> ||
> | backtrace:SyS_socketcall  | 2  | 0  
> | 6  |
> | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22 
> | 13 |
> | BUG:spinlock_bad_magic_on_CPU | 0  | 22 
> ||
> | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22 
> ||
> | EIP_is_at__wake_up_common | 0  | 22 
> ||
> | backtrace:rcu_perf_writer | 0  | 22 
> | 13 |
> | backtrace:sock_setsockopt | 0  | 0  
> | 6  |
> | backtrace:rht_deferred_worker | 0  | 0  
> | 3  |
> +---++++
> 
> [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.6.0-rc1-5-g8704baa #3
> [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.6.0-rc1-5-g8704baa #3
> [1.062485]  
> [1.062485]   cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc 
> c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac 
> cf03bcac
> 
> [1.064620]  c157aa41
> [1.064620]  c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 
> c1ed4958 0202 0202 c100312d c100312d cf03bc80 cf03bc80 c10ab3fb 
> c10ab3fb
> 
> [1.066740]  cf03bc90
> [1.066740]  cf03bc90 0203 0203 cf0a8634 cf0a8634 0382 
> 0382 cf03bcc4 cf03bcc4 c11a701a c11a701a 0010 0010 eb0e29d5 
> eb0e29d5
> 
> [1.068833] Call Trace:
> [1.068833] Call Trace:
> [1.072825]  [] dump_stack+0x16/0x1a
> [1.072825]  [] dump_stack+0x16/0x1a
> [1.073958]  [] ubsan_epilogue+0xb/0x40
> [1.073958]  [] ubsan_epilogue+0xb/0x40
> [1.075151]  [] __ubsan_handle_out_of_bounds+0x61/0x80
> [1.075151]  [] __ubsan_handle_out_of_bounds+0x61/0x80
> [1.080046]  [] ? allocate_fake_cpuc+0x7d/0x90
> [1.080046]  [] ? allocate_fake_cpuc+0x7d/0x90
> [1.081379]  [] ? trace_hardirqs_on+0xb/0x10
> [1.081379]  [] ?

Re: [rcutorture] 8704baab9b: WARNING: CPU: 0 PID: 30 at kernel/rcu/rcuperf.c:363 rcu_perf_writer

2016-05-21 Thread Paul E. McKenney 
On Sun, May 22, 2016 at 10:36:00AM +0800, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit 8704baab9bc848b58c129fed6b591bb84ec02f41
> Author: Paul E. McKenney 
> AuthorDate: Thu Dec 31 18:33:22 2015 -0800
> Commit: Paul E. McKenney 
> CommitDate: Thu Mar 31 13:37:38 2016 -0700
> 
> rcutorture: Add RCU grace-period performance tests
> 
> This commit adds a new rcuperf module that carries out simple performance
> tests of RCU grace periods.
> 
> Signed-off-by: Paul E. McKenney 

???

This commit adds a default-n performance-test module.  I don't believe
that this would result in boot failures.  False bisection?

Thanx, Paul

> +---++++
> |   | 291783b8ad | 
> 8704baab9b | ce82e4a05f |
> +---++++
> | boot_successes| 57 | 0  
> | 0  |
> | boot_failures | 6  | 22 
> | 13 |
> | BUG:unable_to_handle_kernel   | 6  | 22 
> ||
> | Oops  | 6  | 22 
> ||
> | EIP_is_at_get_perf_callchain  | 6  |
> ||
> | Kernel_panic-not_syncing:Fatal_exception  | 5  | 22 
> ||
> | backtrace:acpi_get_cpuid  | 6  | 22 
> | 13 |
> | backtrace:early_init_pdc  | 6  | 22 
> | 13 |
> | backtrace:acpi_early_processor_set_pdc| 6  | 22 
> | 13 |
> | backtrace:acpi_init   | 6  | 22 
> | 13 |
> | backtrace:kernel_init_freeable| 6  | 22 
> | 13 |
> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |
> ||
> | backtrace:vfs_fstatat | 2  |
> ||
> | backtrace:SyS_fstatat64   | 2  |
> ||
> | backtrace:SYSC_socketcall | 2  |
> ||
> | backtrace:SyS_socketcall  | 2  | 0  
> | 6  |
> | WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer  | 0  | 22 
> | 13 |
> | BUG:spinlock_bad_magic_on_CPU | 0  | 22 
> ||
> | BUG:spinlock_lockup_suspected_on_CPU  | 0  | 22 
> ||
> | EIP_is_at__wake_up_common | 0  | 22 
> ||
> | backtrace:rcu_perf_writer | 0  | 22 
> | 13 |
> | backtrace:sock_setsockopt | 0  | 0  
> | 6  |
> | backtrace:rht_deferred_worker | 0  | 0  
> | 3  |
> +---++++
> 
> [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.6.0-rc1-5-g8704baa #3
> [1.054065] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.6.0-rc1-5-g8704baa #3
> [1.062485]  
> [1.062485]   cf03bc70 cf03bc70 cf03bc50 cf03bc50 c15192fc 
> c15192fc cf03bc5c cf03bc5c c157a45b c157a45b c1ed4940 c1ed4940 cf03bcac 
> cf03bcac
> 
> [1.064620]  c157aa41
> [1.064620]  c157aa41 c1bba04c c1bba04c cf03bc74 cf03bc74 c1ed4958 
> c1ed4958 0202 0202 c100312d c100312d cf03bc80 cf03bc80 c10ab3fb 
> c10ab3fb
> 
> [1.066740]  cf03bc90
> [1.066740]  cf03bc90 0203 0203 cf0a8634 cf0a8634 0382 
> 0382 cf03bcc4 cf03bcc4 c11a701a c11a701a 0010 0010 eb0e29d5 
> eb0e29d5
> 
> [1.068833] Call Trace:
> [1.068833] Call Trace:
> [1.072825]  [] dump_stack+0x16/0x1a
> [1.072825]  [] dump_stack+0x16/0x1a
> [1.073958]  [] ubsan_epilogue+0xb/0x40
> [1.073958]  [] ubsan_epilogue+0xb/0x40
> [1.075151]  [] __ubsan_handle_out_of_bounds+0x61/0x80
> [1.075151]  [] __ubsan_handle_out_of_bounds+0x61/0x80
> [1.080046]  [] ? allocate_fake_cpuc+0x7d/0x90
> [1.080046]  [] ? allocate_fake_cpuc+0x7d/0x90
> [1.081379]  [] ? trace_hardirqs_on+0xb/0x10
> [1.081379]  [] ? trace_hardirqs_on+0xb/0x10
> [1.086052]  [] ? slob_free+0x15a/0xa00
> [1.086052]  [] ?