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

Groups > linux.kernel > #1590391 > unrolled thread

Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

Started byBoqun Feng <boqun.feng@gmail.com>
First post2017-03-01 16:10 +0100
Last post2017-03-02 09:50 +0100
Articles 10 — 5 participants

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: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Boqun Feng <boqun.feng@gmail.com> - 2017-03-01 16:10 +0100
    Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Peter Zijlstra <peterz@infradead.org> - 2017-03-01 16:20 +0100
    Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Peter Zijlstra <peterz@infradead.org> - 2017-03-01 17:00 +0100
      Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Chris Wilson <chris@chris-wilson.co.uk> - 2017-03-01 17:20 +0100
        Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Chris Wilson <chris@chris-wilson.co.uk> - 2017-03-01 17:30 +0100
          Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Fengguang Wu <fengguang.wu@intel.com> - 2017-03-01 18:50 +0100
          Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Peter Zijlstra <peterz@infradead.org> - 2017-03-01 22:50 +0100
    Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Peter Zijlstra <peterz@infradead.org> - 2017-03-01 17:00 +0100
      Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at  kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff Fengguang Wu <fengguang.wu@intel.com> - 2017-03-01 17:00 +0100
    [tip:locking/urgent] locking/ww_mutex: Adjust the lock number for  stress test tip-bot for Boqun Feng <tipbot@zytor.com> - 2017-03-02 09:50 +0100

#1590391 — Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

FromBoqun Feng <boqun.feng@gmail.com>
Date2017-03-01 16:10 +0100
SubjectRe: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff
Message-ID<tge39-4N8-51@gated-at.bofh.it>
On Mon, Feb 27, 2017 at 11:35:43AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 27, 2017 at 11:28:24AM +0100, Peter Zijlstra wrote:
> > On Mon, Feb 27, 2017 at 01:14:09PM +0800, Fengguang Wu wrote:
> > > Hello,
> > > 
> > > This bisect result is not satisfactory, however the bug is very
> > > reproducible and looks still alive in mainline&linux-next. You may
> > > try the attached reproduce-* script to debug it.
> > 
> > OK, let me try that, however, see below.
> 
> What that reproduces does is:
> 
> 
> [   17.169056] =====================================
> [   17.171014] [ BUG: bad unlock balance detected! ]
> [   17.172115] 4.10.0-10265-ge5d56ef #18 Not tainted
> [   17.172115] -------------------------------------
> [   17.172115] kworker/u2:0/5 is trying to release lock (ww_class_mutex) at:
> [   17.172115] [<41575474>] ww_mutex_unlock+0x66/0x72
> [   17.172115] but there are no more locks to release!
> [   17.172115] 
> [   17.172115] other info that might help us debug this:
> [   17.172115] 
> [   17.172115] other info that might help us debug this:
> [   17.172115] 4 locks held by kworker/u2:0/5:
> [   17.172115]  #0:  ("test-ww_mutex"){......}, at: [<41041def>] process_one_work+0x168/0x33a
> [   17.172115]  #1:  ((&stress->work)){......}, at: [<41041def>] process_one_work+0x168/0x33a
> [   17.172115]  #2:  (ww_class_acquire){......}, at: [<41041e47>] process_one_work+0x1c0/0x33a
> [   17.172115]  #3:  (ww_class_mutex){......}, at: [<41057d98>] stress_inorder_work+0xbf/0x218
> [   17.172115] 
> [   17.172115] stack backtrace:
> [   17.172115] 
> [   17.172115] stack backtrace:
> [   17.172115] CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 4.10.0-10265-ge5d56ef #18
> [   17.172115] Workqueue: test-ww_mutex stress_inorder_work
> [   17.172115] Call Trace:
> [   17.172115]  dump_stack+0x16/0x18
> [   17.172115]  print_unlock_imbalance_bug+0xb4/0xc1
> [   17.172115]  ? ww_mutex_unlock+0x66/0x72
> [   17.172115]  lock_release+0x28d/0x2bb
> [   17.172115]  ? ww_mutex_unlock+0x66/0x72
> [   17.172115]  __mutex_unlock_slowpath+0x2d/0x1db
> [   17.172115]  ? schedule_hrtimeout_range+0xd/0xf
> [   17.172115]  mutex_unlock+0xb/0xd
> [   17.172115]  ww_mutex_unlock+0x66/0x72
> [   17.172115]  stress_inorder_work+0x10a/0x218
> [   17.172115]  process_one_work+0x1c0/0x33a
> [   17.172115]  ? process_one_work+0x168/0x33a
> [   17.172115]  worker_thread+0x22f/0x315
> [   17.172115]  kthread+0xed/0xf2
> [   17.172115]  ? process_scheduled_works+0x24/0x24
> [   17.172115]  ? __kthread_create_on_node+0x11f/0x11f
> [   17.172115]  ret_from_fork+0x21/0x30
> 
> Which is an entirely different error.. Lemme look into that.

In test-ww_mutex, the stress will use 4096 locks to do the test, and
given held_lock::references only have 12 bits, so I think this is the
reason? I made a patch to reduce the lock number of stress test, and it
seems the problem is resolved.

Thoughts?

Regards,
Boqun

-------------------->8
From: Boqun Feng <boqun.feng@gmail.com>
Date: Wed, 1 Mar 2017 22:50:46 +0800
Subject: [PATCH] locking/ww_mutex: Adjust the lock number for stress test

Because there are only 12 bits in held_lock::references, so we only
support 4095 nested lock held in the same time, adjust the lock number
for ww_mutex stress test to kill one lockdep splat:

[   17.169056] =====================================
[   17.171014] [ BUG: bad unlock balance detected! ]
[   17.172115] 4.10.0-10265-ge5d56ef #18 Not tainted
[   17.172115] -------------------------------------
[   17.172115] kworker/u2:0/5 is trying to release lock (ww_class_mutex) at:
[   17.172115] [<41575474>] ww_mutex_unlock+0x66/0x72
[   17.172115] but there are no more locks to release!
[   17.172115]
[   17.172115] other info that might help us debug this:
[   17.172115]
[   17.172115] other info that might help us debug this:
[   17.172115] 4 locks held by kworker/u2:0/5:
[   17.172115]  #0:  ("test-ww_mutex"){......}, at: [<41041def>] process_one_work+0x168/0x33a
[   17.172115]  #1:  ((&stress->work)){......}, at: [<41041def>] process_one_work+0x168/0x33a
[   17.172115]  #2:  (ww_class_acquire){......}, at: [<41041e47>] process_one_work+0x1c0/0x33a
[   17.172115]  #3:  (ww_class_mutex){......}, at: [<41057d98>] stress_inorder_work+0xbf/0x218
[   17.172115]
[   17.172115] stack backtrace:
[   17.172115]
[   17.172115] stack backtrace:
[   17.172115] CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 4.10.0-10265-ge5d56ef #18
[   17.172115] Workqueue: test-ww_mutex stress_inorder_work
[   17.172115] Call Trace:
[   17.172115]  dump_stack+0x16/0x18
[   17.172115]  print_unlock_imbalance_bug+0xb4/0xc1
[   17.172115]  ? ww_mutex_unlock+0x66/0x72
[   17.172115]  lock_release+0x28d/0x2bb
[   17.172115]  ? ww_mutex_unlock+0x66/0x72
[   17.172115]  __mutex_unlock_slowpath+0x2d/0x1db
[   17.172115]  ? schedule_hrtimeout_range+0xd/0xf
[   17.172115]  mutex_unlock+0xb/0xd
[   17.172115]  ww_mutex_unlock+0x66/0x72
[   17.172115]  stress_inorder_work+0x10a/0x218
[   17.172115]  process_one_work+0x1c0/0x33a
[   17.172115]  ? process_one_work+0x168/0x33a
[   17.172115]  worker_thread+0x22f/0x315
[   17.172115]  kthread+0xed/0xf2
[   17.172115]  ? process_scheduled_works+0x24/0x24
[   17.172115]  ? __kthread_create_on_node+0x11f/0x11f
[   17.172115]  ret_from_fork+0x21/0x30

Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
 kernel/locking/test-ww_mutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index da6c9a34f62f..9155561cca7b 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -627,7 +627,7 @@ static int __init test_ww_mutex_init(void)
 	if (ret)
 		return ret;
 
-	ret = stress(4096, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
+	ret = stress(4095, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
 	if (ret)
 		return ret;
 
-- 
2.11.0

[toc] | [next] | [standalone]

#1590397

FromPeter Zijlstra <peterz@infradead.org>
Date2017-03-01 16:20 +0100
Message-ID<tgecN-4Qr-7@gated-at.bofh.it>
In reply to#1590391
On Wed, Mar 01, 2017 at 11:01:38PM +0800, Boqun Feng wrote:
> 
> In test-ww_mutex, the stress will use 4096 locks to do the test, and
> given held_lock::references only have 12 bits, so I think this is the
> reason? I made a patch to reduce the lock number of stress test, and it
> seems the problem is resolved.
> 
> Thoughts?

Aaaahhh!! YES. I completely overlooked (and forgot) ww_mutex used that.

Let me also do a lockdep patch that complains on overflow there.

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 5 at ../kernel/locking/lockdep.c:3269 __lock_acquire.isra.7+0xf8/0x703
 DEBUG_LOCKS_WARN_ON(hlock->references == (1 << 12)-1)
 CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 4.10.0-01418-gfba4873-dirty #29
 Workqueue: test-ww_mutex stress_inorder_work
 Call Trace:
  dump_stack+0x16/0x18
  __warn+0xa0/0xb7
  ? __lock_acquire.isra.7+0xf8/0x703
  warn_slowpath_fmt+0x28/0x2d
  __lock_acquire.isra.7+0xf8/0x703
  lock_acquire+0x6c/0x95
  ? stress_inorder_work+0xbf/0x218
  __ww_mutex_lock.constprop.0+0x5c/0x848
  ? stress_inorder_work+0xbf/0x218
  ? __might_sleep+0x6c/0x73
  ww_mutex_lock+0x34/0x3b
  ? stress_inorder_work+0xbf/0x218
  stress_inorder_work+0xbf/0x218
  process_one_work+0x1c0/0x33a
  ? process_one_work+0x168/0x33a
  worker_thread+0x22f/0x315
  kthread+0xed/0xf2
  ? process_scheduled_works+0x24/0x24
  ? __kthread_create_on_node+0x11f/0x11f
  ret_from_fork+0x21/0x30
 ---[ end trace 326b6bfcd7100ae8 ]---

---
 kernel/locking/lockdep.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 9812e5dd409e..c0ee8607c11e 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3260,10 +3260,17 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
 	if (depth) {
 		hlock = curr->held_locks + depth - 1;
 		if (hlock->class_idx == class_idx && nest_lock) {
-			if (hlock->references)
+			if (hlock->references) {
+				/*
+				 * Check: unsigned int references:12, overflow.
+				 */
+				if (DEBUG_LOCKS_WARN_ON(hlock->references == (1 << 12)-1))
+					return 0;
+
 				hlock->references++;
-			else
+			} else {
 				hlock->references = 2;
+			}
 
 			return 1;
 		}

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

#1590444

FromPeter Zijlstra <peterz@infradead.org>
Date2017-03-01 17:00 +0100
Message-ID<tgePx-5b2-33@gated-at.bofh.it>
In reply to#1590391
On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
> Add kselftests for ww_mutex stress", and find no "bad unlock balance
> detected" but this warning. Attached is the new dmesg which is a bit
> large due to lots of repeated errors.

So with all the various patches it works for me.

I also have the following on top; which I did when I was looking through
this code trying to figure out wth was happening.

Chris, does this make sense to you?

It makes each loop a fully new 'instance', otherwise we'll never update
the ww_class->stamp and the threads will aways have the same order.

---

diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index da6c9a34f62f..d0fd06429c9d 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -398,12 +398,11 @@ static void stress_inorder_work(struct work_struct *work)
 	if (!order)
 		return;
 
-	ww_acquire_init(&ctx, &ww_class);
-
 	do {
 		int contended = -1;
 		int n, err;
 
+		ww_acquire_init(&ctx, &ww_class);
 retry:
 		err = 0;
 		for (n = 0; n < nlocks; n++) {
@@ -433,9 +432,9 @@ static void stress_inorder_work(struct work_struct *work)
 				    __func__, err);
 			break;
 		}
-	} while (--stress->nloops);
 
-	ww_acquire_fini(&ctx);
+		ww_acquire_fini(&ctx);
+	} while (--stress->nloops);
 
 	kfree(order);
 	kfree(stress);
@@ -470,9 +469,9 @@ static void stress_reorder_work(struct work_struct *work)
 	kfree(order);
 	order = NULL;
 
-	ww_acquire_init(&ctx, &ww_class);
-
 	do {
+		ww_acquire_init(&ctx, &ww_class);
+
 		list_for_each_entry(ll, &locks, link) {
 			err = ww_mutex_lock(ll->lock, &ctx);
 			if (!err)
@@ -495,9 +494,9 @@ static void stress_reorder_work(struct work_struct *work)
 		dummy_load(stress);
 		list_for_each_entry(ll, &locks, link)
 			ww_mutex_unlock(ll->lock);
-	} while (--stress->nloops);
 
-	ww_acquire_fini(&ctx);
+		ww_acquire_fini(&ctx);
+	} while (--stress->nloops);
 
 out:
 	list_for_each_entry_safe(ll, ln, &locks, link)

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

#1590464

FromChris Wilson <chris@chris-wilson.co.uk>
Date2017-03-01 17:20 +0100
Message-ID<tgf8S-5xo-15@gated-at.bofh.it>
In reply to#1590444
On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> > Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
> > Add kselftests for ww_mutex stress", and find no "bad unlock balance
> > detected" but this warning. Attached is the new dmesg which is a bit
> > large due to lots of repeated errors.
> 
> So with all the various patches it works for me.
> 
> I also have the following on top; which I did when I was looking through
> this code trying to figure out wth was happening.
> 
> Chris, does this make sense to you?
> 
> It makes each loop a fully new 'instance', otherwise we'll never update
> the ww_class->stamp and the threads will aways have the same order.

Sounds ok, I just thought the stamp order of the threads was
immaterial - with each test doing a different sequence of locks and each
being identical in behaviour, it would not matter which had priority,
there would have be some shuffling no matter waht. However, for the
purpose of testing, having each iteration be a new locking instance does
make it behaviour more like a typical user.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

#1590497

FromChris Wilson <chris@chris-wilson.co.uk>
Date2017-03-01 17:30 +0100
Message-ID<tgfiz-5AK-29@gated-at.bofh.it>
In reply to#1590464
On Wed, Mar 01, 2017 at 04:11:48PM +0000, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> > > Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
> > > Add kselftests for ww_mutex stress", and find no "bad unlock balance
> > > detected" but this warning. Attached is the new dmesg which is a bit
> > > large due to lots of repeated errors.
> > 
> > So with all the various patches it works for me.
> > 
> > I also have the following on top; which I did when I was looking through
> > this code trying to figure out wth was happening.
> > 
> > Chris, does this make sense to you?
> > 
> > It makes each loop a fully new 'instance', otherwise we'll never update
> > the ww_class->stamp and the threads will aways have the same order.
> 
> Sounds ok, I just thought the stamp order of the threads was
> immaterial - with each test doing a different sequence of locks and each
> being identical in behaviour, it would not matter which had priority,
> there would have be some shuffling no matter waht. However, for the
> purpose of testing, having each iteration be a new locking instance does
> make it behaviour more like a typical user.

Correcting myself, the workers didn't reorder the locks, so changing the
stamp does make the test more interesting.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

#1590532

FromFengguang Wu <fengguang.wu@intel.com>
Date2017-03-01 18:50 +0100
Message-ID<tggxX-6ns-9@gated-at.bofh.it>
In reply to#1590497
On Wed, Mar 01, 2017 at 05:54:06PM +0100, Peter Zijlstra wrote:
>On Wed, Mar 01, 2017 at 04:26:48PM +0000, Chris Wilson wrote:
>> On Wed, Mar 01, 2017 at 04:11:48PM +0000, Chris Wilson wrote:
>> > On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
>> > > On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
>> > > > Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
>> > > > Add kselftests for ww_mutex stress", and find no "bad unlock balance
>> > > > detected" but this warning. Attached is the new dmesg which is a bit
>> > > > large due to lots of repeated errors.
>> > >
>> > > So with all the various patches it works for me.
>> > >
>> > > I also have the following on top; which I did when I was looking through
>> > > this code trying to figure out wth was happening.
>> > >
>> > > Chris, does this make sense to you?
>> > >
>> > > It makes each loop a fully new 'instance', otherwise we'll never update
>> > > the ww_class->stamp and the threads will aways have the same order.
>> >
>> > Sounds ok, I just thought the stamp order of the threads was
>> > immaterial - with each test doing a different sequence of locks and each
>> > being identical in behaviour, it would not matter which had priority,
>> > there would have be some shuffling no matter waht. However, for the
>> > purpose of testing, having each iteration be a new locking instance does
>> > make it behaviour more like a typical user.
>>
>> Correcting myself, the workers didn't reorder the locks, so changing the
>> stamp does make the test more interesting.
>
>OK, so I'll go write a Changelog for it then ;-) And stick your ACK on.

With both patches in this thread, all 110 boots are successful w/o a
single warning.

Tested-by: Fengguang Wu <fengguang.wu@intel.com>

Thanks,
Fengguang

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

#1590641

FromPeter Zijlstra <peterz@infradead.org>
Date2017-03-01 22:50 +0100
Message-ID<tggxX-6ns-11@gated-at.bofh.it>
In reply to#1590497
On Wed, Mar 01, 2017 at 04:26:48PM +0000, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 04:11:48PM +0000, Chris Wilson wrote:
> > On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
> > > On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> > > > Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
> > > > Add kselftests for ww_mutex stress", and find no "bad unlock balance
> > > > detected" but this warning. Attached is the new dmesg which is a bit
> > > > large due to lots of repeated errors.
> > > 
> > > So with all the various patches it works for me.
> > > 
> > > I also have the following on top; which I did when I was looking through
> > > this code trying to figure out wth was happening.
> > > 
> > > Chris, does this make sense to you?
> > > 
> > > It makes each loop a fully new 'instance', otherwise we'll never update
> > > the ww_class->stamp and the threads will aways have the same order.
> > 
> > Sounds ok, I just thought the stamp order of the threads was
> > immaterial - with each test doing a different sequence of locks and each
> > being identical in behaviour, it would not matter which had priority,
> > there would have be some shuffling no matter waht. However, for the
> > purpose of testing, having each iteration be a new locking instance does
> > make it behaviour more like a typical user.
> 
> Correcting myself, the workers didn't reorder the locks, so changing the
> stamp does make the test more interesting.

OK, so I'll go write a Changelog for it then ;-) And stick your ACK on.

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

#1590449

FromPeter Zijlstra <peterz@infradead.org>
Date2017-03-01 17:00 +0100
Message-ID<tgePx-5b2-45@gated-at.bofh.it>
In reply to#1590391
On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
> Add kselftests for ww_mutex stress", and find no "bad unlock balance
> detected" but this warning. Attached is the new dmesg which is a bit
> large due to lots of repeated errors.
> 
> [    9.105427] Freeing initrd memory: 24852K
> [    9.121306] The force parameter has not been set to 1. The Iris poweroff handler will not be installed.
> [    9.141216] NatSemi SCx200 Driver
> [    9.724519] ------------[ cut here ]------------
> [    9.726795] WARNING: CPU: 0 PID: 22 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff+0x31/0x7a
> [    9.738281] CPU: 0 PID: 22 Comm: kworker/u2:1 Not tainted 4.10.0-rc3-00156-g7d81c50 #1
> [    9.741977] Workqueue: test-ww_mutex test_cycle_work
> [    9.745524] Call Trace:
> [    9.747610]  dump_stack+0x16/0x18
> [    9.754619]  __warn+0xa0/0xb7
> [    9.757553]  ? __ww_mutex_wakeup_for_backoff+0x31/0x7a
> [    9.760881]  warn_slowpath_null+0x11/0x16
> [    9.765222]  __ww_mutex_wakeup_for_backoff+0x31/0x7a
> [    9.768028]  __ww_mutex_lock+0x2f3/0xb63
> [    9.770979]  ? wake_up_q+0x25/0x40
> [    9.773044]  ? __might_sleep+0x6c/0x73
> [    9.774890]  ww_mutex_lock+0x34/0x3b
> [    9.776001]  ? test_cycle_work+0xf7/0x170
> [    9.777751]  test_cycle_work+0xf7/0x170
> [    9.779036]  process_one_work+0x1c0/0x33a
> [    9.780664]  ? process_one_work+0x168/0x33a
> [    9.788924]  worker_thread+0x22f/0x315
> [    9.791016]  kthread+0xed/0xf2
> [    9.793255]  ? process_scheduled_works+0x24/0x24
> [    9.795475]  ? __kthread_create_on_node+0x11f/0x11f
> [    9.798741]  ? __kthread_create_on_node+0x11f/0x11f
> [    9.802371]  ret_from_fork+0x19/0x30
> [    9.804430] ---[ end trace 9036bbb174aed804 ]---

Do you have the below patch in?

---
commit b9c16a0e1f733c97e48798b2a9362c485bb3b731
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jan 17 16:06:09 2017 +0100

    locking/mutex: Fix lockdep_assert_held() fail
    
    In commit:
    
      659cf9f5824a ("locking/ww_mutex: Optimize ww-mutexes by waking at most one waiter for backoff when acquiring the lock")
    
    I replaced a comment with a lockdep_assert_held(). However it turns out
    we hide that lock from lockdep for hysterical raisins, which results
    in the assertion always firing.
    
    Remove the old debug code as lockdep will easily spot the abuse it was
    meant to catch, which will make the lock visible to lockdep and make
    the assertion work as intended.
    
    Reported-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nicolai Haehnle <Nicolai.Haehnle@amd.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 659cf9f5824a ("locking/ww_mutex: Optimize ww-mutexes by waking at most one waiter for backoff when acquiring the lock")
    Link: http://lkml.kernel.org/r/20170117150609.GB32474@worktop
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/kernel/locking/mutex-debug.h b/kernel/locking/mutex-debug.h
index a459faa48987..4174417d5309 100644
--- a/kernel/locking/mutex-debug.h
+++ b/kernel/locking/mutex-debug.h
@@ -26,20 +26,3 @@ extern void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
 extern void debug_mutex_unlock(struct mutex *lock);
 extern void debug_mutex_init(struct mutex *lock, const char *name,
 			     struct lock_class_key *key);
-
-#define spin_lock_mutex(lock, flags)			\
-	do {						\
-		struct mutex *l = container_of(lock, struct mutex, wait_lock); \
-							\
-		DEBUG_LOCKS_WARN_ON(in_interrupt());	\
-		local_irq_save(flags);			\
-		arch_spin_lock(&(lock)->rlock.raw_lock);\
-		DEBUG_LOCKS_WARN_ON(l->magic != l);	\
-	} while (0)
-
-#define spin_unlock_mutex(lock, flags)				\
-	do {							\
-		arch_spin_unlock(&(lock)->rlock.raw_lock);	\
-		local_irq_restore(flags);			\
-		preempt_check_resched();			\
-	} while (0)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 935116723a3d..705e06fe5e6c 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -325,8 +325,6 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
 static __always_inline void
 ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
 {
-	unsigned long flags;
-
 	ww_mutex_lock_acquired(lock, ctx);
 
 	lock->ctx = ctx;
@@ -350,9 +348,9 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
 	 * Uh oh, we raced in fastpath, wake up everyone in this case,
 	 * so they can see the new lock->ctx.
 	 */
-	spin_lock_mutex(&lock->base.wait_lock, flags);
+	spin_lock(&lock->base.wait_lock);
 	__ww_mutex_wakeup_for_backoff(&lock->base, ctx);
-	spin_unlock_mutex(&lock->base.wait_lock, flags);
+	spin_unlock(&lock->base.wait_lock);
 }
 
 /*
@@ -740,7 +738,6 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 		    struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
 {
 	struct mutex_waiter waiter;
-	unsigned long flags;
 	bool first = false;
 	struct ww_mutex *ww;
 	int ret;
@@ -766,7 +763,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 		return 0;
 	}
 
-	spin_lock_mutex(&lock->wait_lock, flags);
+	spin_lock(&lock->wait_lock);
 	/*
 	 * After waiting to acquire the wait_lock, try again.
 	 */
@@ -830,7 +827,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 				goto err;
 		}
 
-		spin_unlock_mutex(&lock->wait_lock, flags);
+		spin_unlock(&lock->wait_lock);
 		schedule_preempt_disabled();
 
 		/*
@@ -853,9 +850,9 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 		    (first && mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, &waiter)))
 			break;
 
-		spin_lock_mutex(&lock->wait_lock, flags);
+		spin_lock(&lock->wait_lock);
 	}
-	spin_lock_mutex(&lock->wait_lock, flags);
+	spin_lock(&lock->wait_lock);
 acquired:
 	__set_current_state(TASK_RUNNING);
 
@@ -872,7 +869,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 	if (use_ww_ctx && ww_ctx)
 		ww_mutex_set_context_slowpath(ww, ww_ctx);
 
-	spin_unlock_mutex(&lock->wait_lock, flags);
+	spin_unlock(&lock->wait_lock);
 	preempt_enable();
 	return 0;
 
@@ -880,7 +877,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 	__set_current_state(TASK_RUNNING);
 	mutex_remove_waiter(lock, &waiter, current);
 err_early_backoff:
-	spin_unlock_mutex(&lock->wait_lock, flags);
+	spin_unlock(&lock->wait_lock);
 	debug_mutex_free_waiter(&waiter);
 	mutex_release(&lock->dep_map, 1, ip);
 	preempt_enable();
@@ -999,8 +996,8 @@ EXPORT_SYMBOL_GPL(ww_mutex_lock_interruptible);
 static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip)
 {
 	struct task_struct *next = NULL;
-	unsigned long owner, flags;
 	DEFINE_WAKE_Q(wake_q);
+	unsigned long owner;
 
 	mutex_release(&lock->dep_map, 1, ip);
 
@@ -1035,7 +1032,7 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
 		owner = old;
 	}
 
-	spin_lock_mutex(&lock->wait_lock, flags);
+	spin_lock(&lock->wait_lock);
 	debug_mutex_unlock(lock);
 	if (!list_empty(&lock->wait_list)) {
 		/* get the first entry from the wait-list: */
@@ -1052,7 +1049,7 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
 	if (owner & MUTEX_FLAG_HANDOFF)
 		__mutex_handoff(lock, next);
 
-	spin_unlock_mutex(&lock->wait_lock, flags);
+	spin_unlock(&lock->wait_lock);
 
 	wake_up_q(&wake_q);
 }
diff --git a/kernel/locking/mutex.h b/kernel/locking/mutex.h
index 4410a4af42a3..6ebc1902f779 100644
--- a/kernel/locking/mutex.h
+++ b/kernel/locking/mutex.h
@@ -9,10 +9,6 @@
  * !CONFIG_DEBUG_MUTEXES case. Most of them are NOPs:
  */
 
-#define spin_lock_mutex(lock, flags) \
-		do { spin_lock(lock); (void)(flags); } while (0)
-#define spin_unlock_mutex(lock, flags) \
-		do { spin_unlock(lock); (void)(flags); } while (0)
 #define mutex_remove_waiter(lock, waiter, task) \
 		__list_del((waiter)->list.prev, (waiter)->list.next)

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

#1590453

FromFengguang Wu <fengguang.wu@intel.com>
Date2017-03-01 17:00 +0100
Message-ID<tgePx-5b2-51@gated-at.bofh.it>
In reply to#1590449
On Wed, Mar 01, 2017 at 04:51:36PM +0100, Peter Zijlstra wrote:
>On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
>> Thanks for the patch! I applied the patch on top of "locking/ww_mutex:
>> Add kselftests for ww_mutex stress", and find no "bad unlock balance
>> detected" but this warning. Attached is the new dmesg which is a bit
>> large due to lots of repeated errors.
>>
>> [    9.105427] Freeing initrd memory: 24852K
>> [    9.121306] The force parameter has not been set to 1. The Iris poweroff handler will not be installed.
>> [    9.141216] NatSemi SCx200 Driver
>> [    9.724519] ------------[ cut here ]------------
>> [    9.726795] WARNING: CPU: 0 PID: 22 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff+0x31/0x7a
>> [    9.738281] CPU: 0 PID: 22 Comm: kworker/u2:1 Not tainted 4.10.0-rc3-00156-g7d81c50 #1
>> [    9.741977] Workqueue: test-ww_mutex test_cycle_work
>> [    9.745524] Call Trace:
>> [    9.747610]  dump_stack+0x16/0x18
>> [    9.754619]  __warn+0xa0/0xb7
>> [    9.757553]  ? __ww_mutex_wakeup_for_backoff+0x31/0x7a
>> [    9.760881]  warn_slowpath_null+0x11/0x16
>> [    9.765222]  __ww_mutex_wakeup_for_backoff+0x31/0x7a
>> [    9.768028]  __ww_mutex_lock+0x2f3/0xb63
>> [    9.770979]  ? wake_up_q+0x25/0x40
>> [    9.773044]  ? __might_sleep+0x6c/0x73
>> [    9.774890]  ww_mutex_lock+0x34/0x3b
>> [    9.776001]  ? test_cycle_work+0xf7/0x170
>> [    9.777751]  test_cycle_work+0xf7/0x170
>> [    9.779036]  process_one_work+0x1c0/0x33a
>> [    9.780664]  ? process_one_work+0x168/0x33a
>> [    9.788924]  worker_thread+0x22f/0x315
>> [    9.791016]  kthread+0xed/0xf2
>> [    9.793255]  ? process_scheduled_works+0x24/0x24
>> [    9.795475]  ? __kthread_create_on_node+0x11f/0x11f
>> [    9.798741]  ? __kthread_create_on_node+0x11f/0x11f
>> [    9.802371]  ret_from_fork+0x19/0x30
>> [    9.804430] ---[ end trace 9036bbb174aed804 ]---
>
>Do you have the below patch in?

Nope. I'll re-test with it added.

Regards,
Fengguang

>---
>commit b9c16a0e1f733c97e48798b2a9362c485bb3b731
>Author: Peter Zijlstra <peterz@infradead.org>
>Date:   Tue Jan 17 16:06:09 2017 +0100
>
>    locking/mutex: Fix lockdep_assert_held() fail
>
>    In commit:
>
>      659cf9f5824a ("locking/ww_mutex: Optimize ww-mutexes by waking at most one waiter for backoff when acquiring the lock")
>
>    I replaced a comment with a lockdep_assert_held(). However it turns out
>    we hide that lock from lockdep for hysterical raisins, which results
>    in the assertion always firing.
>
>    Remove the old debug code as lockdep will easily spot the abuse it was
>    meant to catch, which will make the lock visible to lockdep and make
>    the assertion work as intended.
>
>    Reported-by: Mike Galbraith <efault@gmx.de>
>    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>    Cc: Linus Torvalds <torvalds@linux-foundation.org>
>    Cc: Nicolai Haehnle <Nicolai.Haehnle@amd.com>
>    Cc: Peter Zijlstra <peterz@infradead.org>
>    Cc: Thomas Gleixner <tglx@linutronix.de>
>    Fixes: 659cf9f5824a ("locking/ww_mutex: Optimize ww-mutexes by waking at most one waiter for backoff when acquiring the lock")
>    Link: http://lkml.kernel.org/r/20170117150609.GB32474@worktop
>    Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
>diff --git a/kernel/locking/mutex-debug.h b/kernel/locking/mutex-debug.h
>index a459faa48987..4174417d5309 100644
>--- a/kernel/locking/mutex-debug.h
>+++ b/kernel/locking/mutex-debug.h
>@@ -26,20 +26,3 @@ extern void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
> extern void debug_mutex_unlock(struct mutex *lock);
> extern void debug_mutex_init(struct mutex *lock, const char *name,
> 			     struct lock_class_key *key);
>-
>-#define spin_lock_mutex(lock, flags)			\
>-	do {						\
>-		struct mutex *l = container_of(lock, struct mutex, wait_lock); \
>-							\
>-		DEBUG_LOCKS_WARN_ON(in_interrupt());	\
>-		local_irq_save(flags);			\
>-		arch_spin_lock(&(lock)->rlock.raw_lock);\
>-		DEBUG_LOCKS_WARN_ON(l->magic != l);	\
>-	} while (0)
>-
>-#define spin_unlock_mutex(lock, flags)				\
>-	do {							\
>-		arch_spin_unlock(&(lock)->rlock.raw_lock);	\
>-		local_irq_restore(flags);			\
>-		preempt_check_resched();			\
>-	} while (0)
>diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
>index 935116723a3d..705e06fe5e6c 100644
>--- a/kernel/locking/mutex.c
>+++ b/kernel/locking/mutex.c
>@@ -325,8 +325,6 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
> static __always_inline void
> ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
> {
>-	unsigned long flags;
>-
> 	ww_mutex_lock_acquired(lock, ctx);
>
> 	lock->ctx = ctx;
>@@ -350,9 +348,9 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
> 	 * Uh oh, we raced in fastpath, wake up everyone in this case,
> 	 * so they can see the new lock->ctx.
> 	 */
>-	spin_lock_mutex(&lock->base.wait_lock, flags);
>+	spin_lock(&lock->base.wait_lock);
> 	__ww_mutex_wakeup_for_backoff(&lock->base, ctx);
>-	spin_unlock_mutex(&lock->base.wait_lock, flags);
>+	spin_unlock(&lock->base.wait_lock);
> }
>
> /*
>@@ -740,7 +738,6 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 		    struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
> {
> 	struct mutex_waiter waiter;
>-	unsigned long flags;
> 	bool first = false;
> 	struct ww_mutex *ww;
> 	int ret;
>@@ -766,7 +763,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 		return 0;
> 	}
>
>-	spin_lock_mutex(&lock->wait_lock, flags);
>+	spin_lock(&lock->wait_lock);
> 	/*
> 	 * After waiting to acquire the wait_lock, try again.
> 	 */
>@@ -830,7 +827,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 				goto err;
> 		}
>
>-		spin_unlock_mutex(&lock->wait_lock, flags);
>+		spin_unlock(&lock->wait_lock);
> 		schedule_preempt_disabled();
>
> 		/*
>@@ -853,9 +850,9 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 		    (first && mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, &waiter)))
> 			break;
>
>-		spin_lock_mutex(&lock->wait_lock, flags);
>+		spin_lock(&lock->wait_lock);
> 	}
>-	spin_lock_mutex(&lock->wait_lock, flags);
>+	spin_lock(&lock->wait_lock);
> acquired:
> 	__set_current_state(TASK_RUNNING);
>
>@@ -872,7 +869,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 	if (use_ww_ctx && ww_ctx)
> 		ww_mutex_set_context_slowpath(ww, ww_ctx);
>
>-	spin_unlock_mutex(&lock->wait_lock, flags);
>+	spin_unlock(&lock->wait_lock);
> 	preempt_enable();
> 	return 0;
>
>@@ -880,7 +877,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> 	__set_current_state(TASK_RUNNING);
> 	mutex_remove_waiter(lock, &waiter, current);
> err_early_backoff:
>-	spin_unlock_mutex(&lock->wait_lock, flags);
>+	spin_unlock(&lock->wait_lock);
> 	debug_mutex_free_waiter(&waiter);
> 	mutex_release(&lock->dep_map, 1, ip);
> 	preempt_enable();
>@@ -999,8 +996,8 @@ EXPORT_SYMBOL_GPL(ww_mutex_lock_interruptible);
> static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip)
> {
> 	struct task_struct *next = NULL;
>-	unsigned long owner, flags;
> 	DEFINE_WAKE_Q(wake_q);
>+	unsigned long owner;
>
> 	mutex_release(&lock->dep_map, 1, ip);
>
>@@ -1035,7 +1032,7 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
> 		owner = old;
> 	}
>
>-	spin_lock_mutex(&lock->wait_lock, flags);
>+	spin_lock(&lock->wait_lock);
> 	debug_mutex_unlock(lock);
> 	if (!list_empty(&lock->wait_list)) {
> 		/* get the first entry from the wait-list: */
>@@ -1052,7 +1049,7 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
> 	if (owner & MUTEX_FLAG_HANDOFF)
> 		__mutex_handoff(lock, next);
>
>-	spin_unlock_mutex(&lock->wait_lock, flags);
>+	spin_unlock(&lock->wait_lock);
>
> 	wake_up_q(&wake_q);
> }
>diff --git a/kernel/locking/mutex.h b/kernel/locking/mutex.h
>index 4410a4af42a3..6ebc1902f779 100644
>--- a/kernel/locking/mutex.h
>+++ b/kernel/locking/mutex.h
>@@ -9,10 +9,6 @@
>  * !CONFIG_DEBUG_MUTEXES case. Most of them are NOPs:
>  */
>
>-#define spin_lock_mutex(lock, flags) \
>-		do { spin_lock(lock); (void)(flags); } while (0)
>-#define spin_unlock_mutex(lock, flags) \
>-		do { spin_unlock(lock); (void)(flags); } while (0)
> #define mutex_remove_waiter(lock, waiter, task) \
> 		__list_del((waiter)->list.prev, (waiter)->list.next)
>

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

#1590924 — [tip:locking/urgent] locking/ww_mutex: Adjust the lock number for stress test

Fromtip-bot for Boqun Feng <tipbot@zytor.com>
Date2017-03-02 09:50 +0100
Subject[tip:locking/urgent] locking/ww_mutex: Adjust the lock number for stress test
Message-ID<tguAW-856-29@gated-at.bofh.it>
In reply to#1590391
Commit-ID:  857811a37129f5d2ba162d7be3986eff44724014
Gitweb:     http://git.kernel.org/tip/857811a37129f5d2ba162d7be3986eff44724014
Author:     Boqun Feng <boqun.feng@gmail.com>
AuthorDate: Wed, 1 Mar 2017 23:01:38 +0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 2 Mar 2017 09:00:39 +0100

locking/ww_mutex: Adjust the lock number for stress test

Because there are only 12 bits in held_lock::references, so we only
support 4095 nested lock held in the same time, adjust the lock number
for ww_mutex stress test to kill one lockdep splat:

  [ ] [ BUG: bad unlock balance detected! ]
  [ ] kworker/u2:0/5 is trying to release lock (ww_class_mutex) at:
  [ ] ww_mutex_unlock()
  [ ] but there are no more locks to release!
  ...

Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicolai Hähnle <Nicolai.Haehnle@amd.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170301150138.hdixnmafzfsox7nn@tardis.cn.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/locking/test-ww_mutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
index 3eb39c5..6b7abb3 100644
--- a/kernel/locking/test-ww_mutex.c
+++ b/kernel/locking/test-ww_mutex.c
@@ -627,7 +627,7 @@ static int __init test_ww_mutex_init(void)
 	if (ret)
 		return ret;
 
-	ret = stress(4096, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
+	ret = stress(4095, hweight32(STRESS_ALL)*ncpus, 1<<12, STRESS_ALL);
 	if (ret)
 		return ret;

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web