Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1670942 > unrolled thread

Re: WARN_ON_ONCE() in process_one_work()?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: WARN_ON_ONCE() in process_one_work()? "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-06-20 18:50 +0200
    Re: WARN_ON_ONCE() in process_one_work()? "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-06-21 22:10 +0200
      Re: WARN_ON_ONCE() in process_one_work()? "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-06-23 18:50 +0200
        Re: WARN_ON_ONCE() in process_one_work()? "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-06-27 18:30 +0200

#1670942 — Re: WARN_ON_ONCE() in process_one_work()?

On Sun, Jun 18, 2017 at 06:40:00AM -0400, Tejun Heo wrote:
> Hello,
> 
> On Sat, Jun 17, 2017 at 10:31:05AM -0700, Paul E. McKenney wrote:
> > On Sat, Jun 17, 2017 at 07:53:14AM -0400, Tejun Heo wrote:
> > > Hello,
> > > 
> > > On Fri, Jun 16, 2017 at 10:36:58AM -0700, Paul E. McKenney wrote:
> > > > And no test failures from yesterday evening.  So it looks like we get
> > > > somewhere on the order of one failure per 138 hours of TREE07 rcutorture
> > > > runtime with your printk() in the mix.
> > > >
> > > > Was the above output from your printk() output of any help?
> > > 
> > > Yeah, if my suspicion is correct, it'd require new kworker creation
> > > racing against CPU offline, which would explain why it's so difficult
> > > to repro.  Can you please see whether the following patch resolves the
> > > issue?
> > 
> > That could explain why only Steve Rostedt and I saw the issue.  As far
> > as I know, we are the only ones who regularly run CPU-hotplug stress
> > tests.  ;-)
> 
> I was a bit confused.  It has to be racing against either new kworker
> being created on the wrong CPU or rescuer trying to migrate to the
> CPU, and it looks like we're mostly seeing the rescuer condition, but,
> yeah, this would only get triggered rarely.  Another contributing
> factor could be the vmstat work putting on a workqueue w/ rescuer
> recently.  It runs quite often, so probably has increased the chance
> of hitting the right condition.

Sounds like too much fun!  ;-)

But more constructively...  If I understand correctly, it is now possible
to take a CPU partially offline and put it back online again.  This should
allow much more intense testing of this sort of interaction.

And no, I haven't yet tried this with RCU because I would probably need
to do some mix of just-RCU online/offline and full-up online-offline.
Plus RCU requires pretty much a full online/offline cycle to fully
exercise it.  :-/

> > I have a weekend-long run going, but will give this a shot overnight on
> > Monday, Pacific Time.  Thank you for putting it together, looking forward
> > to seeing what it does!
> 
> Thanks a lot for the testing and patience.  Sorry that it took so
> long.  I'm not completely sure the patch is correct.  It might have to
> be more specifc about which type of migration or require further
> synchronization around migration, but hopefully it'll at least be able
> to show that this was the cause of the problem.

And last night's tests had no failures.  Which might actually mean
something, will get more info when I run without your patch this
evening.  ;-)

							Thanx, Paul

[toc] | [next] | [standalone]

#1671998

On Tue, Jun 20, 2017 at 09:45:23AM -0700, Paul E. McKenney wrote:
> On Sun, Jun 18, 2017 at 06:40:00AM -0400, Tejun Heo wrote:
> > Hello,
> > 
> > On Sat, Jun 17, 2017 at 10:31:05AM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 17, 2017 at 07:53:14AM -0400, Tejun Heo wrote:
> > > > Hello,
> > > > 
> > > > On Fri, Jun 16, 2017 at 10:36:58AM -0700, Paul E. McKenney wrote:
> > > > > And no test failures from yesterday evening.  So it looks like we get
> > > > > somewhere on the order of one failure per 138 hours of TREE07 rcutorture
> > > > > runtime with your printk() in the mix.
> > > > >
> > > > > Was the above output from your printk() output of any help?
> > > > 
> > > > Yeah, if my suspicion is correct, it'd require new kworker creation
> > > > racing against CPU offline, which would explain why it's so difficult
> > > > to repro.  Can you please see whether the following patch resolves the
> > > > issue?
> > > 
> > > That could explain why only Steve Rostedt and I saw the issue.  As far
> > > as I know, we are the only ones who regularly run CPU-hotplug stress
> > > tests.  ;-)
> > 
> > I was a bit confused.  It has to be racing against either new kworker
> > being created on the wrong CPU or rescuer trying to migrate to the
> > CPU, and it looks like we're mostly seeing the rescuer condition, but,
> > yeah, this would only get triggered rarely.  Another contributing
> > factor could be the vmstat work putting on a workqueue w/ rescuer
> > recently.  It runs quite often, so probably has increased the chance
> > of hitting the right condition.
> 
> Sounds like too much fun!  ;-)
> 
> But more constructively...  If I understand correctly, it is now possible
> to take a CPU partially offline and put it back online again.  This should
> allow much more intense testing of this sort of interaction.
> 
> And no, I haven't yet tried this with RCU because I would probably need
> to do some mix of just-RCU online/offline and full-up online-offline.
> Plus RCU requires pretty much a full online/offline cycle to fully
> exercise it.  :-/
> 
> > > I have a weekend-long run going, but will give this a shot overnight on
> > > Monday, Pacific Time.  Thank you for putting it together, looking forward
> > > to seeing what it does!
> > 
> > Thanks a lot for the testing and patience.  Sorry that it took so
> > long.  I'm not completely sure the patch is correct.  It might have to
> > be more specifc about which type of migration or require further
> > synchronization around migration, but hopefully it'll at least be able
> > to show that this was the cause of the problem.
> 
> And last night's tests had no failures.  Which might actually mean
> something, will get more info when I run without your patch this
> evening.  ;-)

And it didn't fail without the patch, either.  45 hours of test vs.
60 hours with the patch.  This one is not going to be easy to prove
either way.  I will try again this evening without the patch and see
what that gets us.

							Thanx, Paul

[toc] | [prev] | [next] | [standalone]

#1673678

On Wed, Jun 21, 2017 at 08:30:35AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 20, 2017 at 09:45:23AM -0700, Paul E. McKenney wrote:
> > On Sun, Jun 18, 2017 at 06:40:00AM -0400, Tejun Heo wrote:
> > > Hello,
> > > 
> > > On Sat, Jun 17, 2017 at 10:31:05AM -0700, Paul E. McKenney wrote:
> > > > On Sat, Jun 17, 2017 at 07:53:14AM -0400, Tejun Heo wrote:
> > > > > Hello,
> > > > > 
> > > > > On Fri, Jun 16, 2017 at 10:36:58AM -0700, Paul E. McKenney wrote:
> > > > > > And no test failures from yesterday evening.  So it looks like we get
> > > > > > somewhere on the order of one failure per 138 hours of TREE07 rcutorture
> > > > > > runtime with your printk() in the mix.
> > > > > >
> > > > > > Was the above output from your printk() output of any help?
> > > > > 
> > > > > Yeah, if my suspicion is correct, it'd require new kworker creation
> > > > > racing against CPU offline, which would explain why it's so difficult
> > > > > to repro.  Can you please see whether the following patch resolves the
> > > > > issue?
> > > > 
> > > > That could explain why only Steve Rostedt and I saw the issue.  As far
> > > > as I know, we are the only ones who regularly run CPU-hotplug stress
> > > > tests.  ;-)
> > > 
> > > I was a bit confused.  It has to be racing against either new kworker
> > > being created on the wrong CPU or rescuer trying to migrate to the
> > > CPU, and it looks like we're mostly seeing the rescuer condition, but,
> > > yeah, this would only get triggered rarely.  Another contributing
> > > factor could be the vmstat work putting on a workqueue w/ rescuer
> > > recently.  It runs quite often, so probably has increased the chance
> > > of hitting the right condition.
> > 
> > Sounds like too much fun!  ;-)
> > 
> > But more constructively...  If I understand correctly, it is now possible
> > to take a CPU partially offline and put it back online again.  This should
> > allow much more intense testing of this sort of interaction.
> > 
> > And no, I haven't yet tried this with RCU because I would probably need
> > to do some mix of just-RCU online/offline and full-up online-offline.
> > Plus RCU requires pretty much a full online/offline cycle to fully
> > exercise it.  :-/
> > 
> > > > I have a weekend-long run going, but will give this a shot overnight on
> > > > Monday, Pacific Time.  Thank you for putting it together, looking forward
> > > > to seeing what it does!
> > > 
> > > Thanks a lot for the testing and patience.  Sorry that it took so
> > > long.  I'm not completely sure the patch is correct.  It might have to
> > > be more specifc about which type of migration or require further
> > > synchronization around migration, but hopefully it'll at least be able
> > > to show that this was the cause of the problem.
> > 
> > And last night's tests had no failures.  Which might actually mean
> > something, will get more info when I run without your patch this
> > evening.  ;-)
> 
> And it didn't fail without the patch, either.  45 hours of test vs.
> 60 hours with the patch.  This one is not going to be easy to prove
> either way.  I will try again this evening without the patch and see
> what that gets us.

And another 36 hours (total of 81 hours) without the patch, still no
failure.  Sigh.

In the sense that the patch doesn't cause any new problem:

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

But I clearly have nothing of statistical significance, so any confidence
in the fix is coming from your reproducer.

							Thanx, Paul

[toc] | [prev] | [next] | [standalone]

#1675986

On Fri, Jun 23, 2017 at 09:41:42AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 21, 2017 at 08:30:35AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 20, 2017 at 09:45:23AM -0700, Paul E. McKenney wrote:
> > > On Sun, Jun 18, 2017 at 06:40:00AM -0400, Tejun Heo wrote:
> > > > Hello,
> > > > 
> > > > On Sat, Jun 17, 2017 at 10:31:05AM -0700, Paul E. McKenney wrote:
> > > > > On Sat, Jun 17, 2017 at 07:53:14AM -0400, Tejun Heo wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > On Fri, Jun 16, 2017 at 10:36:58AM -0700, Paul E. McKenney wrote:
> > > > > > > And no test failures from yesterday evening.  So it looks like we get
> > > > > > > somewhere on the order of one failure per 138 hours of TREE07 rcutorture
> > > > > > > runtime with your printk() in the mix.
> > > > > > >
> > > > > > > Was the above output from your printk() output of any help?
> > > > > > 
> > > > > > Yeah, if my suspicion is correct, it'd require new kworker creation
> > > > > > racing against CPU offline, which would explain why it's so difficult
> > > > > > to repro.  Can you please see whether the following patch resolves the
> > > > > > issue?
> > > > > 
> > > > > That could explain why only Steve Rostedt and I saw the issue.  As far
> > > > > as I know, we are the only ones who regularly run CPU-hotplug stress
> > > > > tests.  ;-)
> > > > 
> > > > I was a bit confused.  It has to be racing against either new kworker
> > > > being created on the wrong CPU or rescuer trying to migrate to the
> > > > CPU, and it looks like we're mostly seeing the rescuer condition, but,
> > > > yeah, this would only get triggered rarely.  Another contributing
> > > > factor could be the vmstat work putting on a workqueue w/ rescuer
> > > > recently.  It runs quite often, so probably has increased the chance
> > > > of hitting the right condition.
> > > 
> > > Sounds like too much fun!  ;-)
> > > 
> > > But more constructively...  If I understand correctly, it is now possible
> > > to take a CPU partially offline and put it back online again.  This should
> > > allow much more intense testing of this sort of interaction.
> > > 
> > > And no, I haven't yet tried this with RCU because I would probably need
> > > to do some mix of just-RCU online/offline and full-up online-offline.
> > > Plus RCU requires pretty much a full online/offline cycle to fully
> > > exercise it.  :-/
> > > 
> > > > > I have a weekend-long run going, but will give this a shot overnight on
> > > > > Monday, Pacific Time.  Thank you for putting it together, looking forward
> > > > > to seeing what it does!
> > > > 
> > > > Thanks a lot for the testing and patience.  Sorry that it took so
> > > > long.  I'm not completely sure the patch is correct.  It might have to
> > > > be more specifc about which type of migration or require further
> > > > synchronization around migration, but hopefully it'll at least be able
> > > > to show that this was the cause of the problem.
> > > 
> > > And last night's tests had no failures.  Which might actually mean
> > > something, will get more info when I run without your patch this
> > > evening.  ;-)
> > 
> > And it didn't fail without the patch, either.  45 hours of test vs.
> > 60 hours with the patch.  This one is not going to be easy to prove
> > either way.  I will try again this evening without the patch and see
> > what that gets us.
> 
> And another 36 hours (total of 81 hours) without the patch, still no
> failure.  Sigh.
> 
> In the sense that the patch doesn't cause any new problem:
> 
> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> But I clearly have nothing of statistical significance, so any confidence
> in the fix is coming from your reproducer.

And for whatever it is worth, I did finally get a reproduction without
the patch.  The probability of occurrence is quite low with my test setup,
so please queue this patch.  I will accumulate test time on it over the
months to come.  :-/

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web