swait: Remove the lockless swait_active() check in swake_up*()
PATCH 1/1 swait: Remove the lockless swait_active() check in swake_up*()
Steven Rostedt reported a potential race in RCU core because of swake_up():
CPU0 CPU1
---- ----
__call_rcu_core() {
spin_lock(rnp_root)
need_wake = __rcu_start_gp() {
rcu_start_gp_advanced() {
gp_flags = FLAG_INIT
}
} rcu_gp_kthread() {
swait_event_interruptible(wq,
gp_flags & FLAG_INIT) { spin_lock(q->lock)
*fetch wq->task_list here! *
list_add(wq->task_list, q->task_list) spin_unlock(q->lock);
*fetch old value of gp_flags here *
spin_unlock(rnp_root)
rcu_gp_kthread_wake() {
swake_up(wq) {
swait_active(wq) {
list_empty(wq->task_list)
} * return false * if (condition) * false *
schedule();In this case, a wakeup is missed, which could cause the rcu_gp_kthread waits for a long time.
The reason of this is that we do a lockless swait_active() check in swake_up(). To fix this, we can either 1) add a smp_mb() in swake_up() before swait_active() to provide the proper order or 2) simply remove the swait_active() in swake_up().
The solution 2 not only fixes this problem but also keeps the swait and wait API as close as possible, as wake_up() doesn't provide a full barrier and doesn't do a lockless check of the wait queue either. Moreover, there are users already using swait_active() to do their quick checks for the wait queues, so it make less sense that swake_up() and swake_up_all() do this on their own.
This patch then removes the lockless swait_active() check in swake_up() and swake_up_all().
--- kernel/sched/swait.c | 6 ------ 1 file changed, 6 deletions(-)
kernel/sched/swait.c +0 -6
@@ -33,9 +33,6 @@ void swake_up(struct swait_queue_head *q) {unsigned long flags; -if (!swait_active (q)) -return ; -raw_spin_lock_irqsave (&q->lock, flags);swake_up_locked (q);raw_spin_unlock_irqrestore (&q->lock, flags);
@@ -51,9 +48,6 @@ void swake_up_all(struct swait_queue_head *q)struct swait_queue *curr;LIST_HEAD (tmp); -if (!swait_active (q)) -return ; -raw_spin_lock_irq (&q->lock);list_splice_init (&q->task_list, &tmp);while (!list_empty (&tmp)) {
Signature · 1 line
2.13.3
Quoted 53 lines · Boqun Feng
Steven Rostedt reported a potential race in RCU core because of
swake_up():CPU0 CPU1 ---- ---- __call_rcu_core() { spin_lock(rnp_root) need_wake = __rcu_start_gp() { rcu_start_gp_advanced() { gp_flags = FLAG_INIT } }rcu_gp_kthread() { swait_event_interruptible(wq, gp_flags & FLAG_INIT) { spin_lock(q->lock) *fetch wq->task_list here! * list_add(wq->task_list, q->task_list) spin_unlock(q->lock); *fetch old value of gp_flags here * spin_unlock(rnp_root) rcu_gp_kthread_wake() { swake_up(wq) { swait_active(wq) { list_empty(wq->task_list) } * return false *if (condition) * false * schedule();In this case, a wakeup is missed, which could cause the
rcu_gp_kthreadwaits for a long time.The reason of this is that we do a lockless
swait_active()check inswake_up(). To fix this, we can either 1) add asmp_mb()inswake_up()beforeswait_active()to provide the proper order or 2) simply remove theswait_active()inswake_up().The solution 2 not only fixes this problem but also keeps the swait and wait API as close as possible, as
wake_up()doesn't provide a full barrier and doesn't do a lockless check of the wait queue either. Moreover, there are users already usingswait_active()to do their quick checks for the wait queues, so it make less sense thatswake_up()andswake_up_all()do this on their own.
Quoted 7 lines
This patch then removes the lockless
swait_active()check inswake_up()andswake_up_all().Reported-by Steven Rostedt <[email protected]>Signed-off-by Boqun Feng <[email protected]>Acked-by Paul E. McKenney <[email protected]>Tested-by Paul E. McKenney <[email protected]>
Hearing no objections but not hearing anything else, either, I have queued this for v4.14. If someone else would rather queue it, please let me know.
Thanx, Paul
Quoted 31 lines
--- kernel/sched/swait.c | 6 ------ 1 file changed, 6 deletions(-)kernel/sched/swait.c +0
-6@@ -33,9 +33,6 @@ void swake_up(struct swait_queue_head *q) {unsigned long flags; -if (!swait_active (q)) -return ; -raw_spin_lock_irqsave (&q->lock, flags);swake_up_locked (q);raw_spin_unlock_irqrestore (&q->lock, flags);@@ -51,9 +48,6 @@ void swake_up_all(struct swait_queue_head *q)struct swait_queue *curr;LIST_HEAD (tmp); -if (!swait_active (q)) -return ; -raw_spin_lock_irq (&q->lock);list_splice_init (&q->task_list, &tmp);while (!list_empty (&tmp)) {Signature · 1 line
2.13.3
Peter Zijlstra
maintainerQuoted 57 lines · Paul E. McKenney
Quoted 56 lines · Boqun Feng
Steven Rostedt reported a potential race in RCU core because of
swake_up():CPU0 CPU1 ---- ---- __call_rcu_core() { spin_lock(rnp_root) need_wake = __rcu_start_gp() { rcu_start_gp_advanced() { gp_flags = FLAG_INIT } }rcu_gp_kthread() { swait_event_interruptible(wq, gp_flags & FLAG_INIT) { spin_lock(q->lock) *fetch wq->task_list here! * list_add(wq->task_list, q->task_list) spin_unlock(q->lock); *fetch old value of gp_flags here * spin_unlock(rnp_root) rcu_gp_kthread_wake() { swake_up(wq) { swait_active(wq) { list_empty(wq->task_list) } * return false *if (condition) * false * schedule();In this case, a wakeup is missed, which could cause the
rcu_gp_kthreadwaits for a long time.The reason of this is that we do a lockless
swait_active()check inswake_up(). To fix this, we can either 1) add asmp_mb()inswake_up()beforeswait_active()to provide the proper order or 2) simply remove theswait_active()inswake_up().The solution 2 not only fixes this problem but also keeps the swait and wait API as close as possible, as
wake_up()doesn't provide a full barrier and doesn't do a lockless check of the wait queue either. Moreover, there are users already usingswait_active()to do their quick checks for the wait queues, so it make less sense thatswake_up()andswake_up_all()do this on their own.This patch then removes the lockless
swait_active()check inswake_up()andswake_up_all().
Quoted 8 lines
Quoted 4 lines
Reported-by Steven Rostedt <[email protected]>Signed-off-by Boqun Feng <[email protected]>Acked-by Paul E. McKenney <[email protected]>Tested-by Paul E. McKenney <[email protected]>Hearing no objections but not hearing anything else, either, I have queued this for v4.14. If someone else would rather queue it, please let me know.
I have it too. Lets see who can get it into -tip first :-)
Quoted 63 lines · Peter Zijlstra
Quoted 62 lines · Paul E. McKenney
Quoted 60 lines · Boqun Feng
Steven Rostedt reported a potential race in RCU core because of
swake_up():CPU0 CPU1 ---- ---- __call_rcu_core() { spin_lock(rnp_root) need_wake = __rcu_start_gp() { rcu_start_gp_advanced() { gp_flags = FLAG_INIT } }rcu_gp_kthread() { swait_event_interruptible(wq, gp_flags & FLAG_INIT) { spin_lock(q->lock) *fetch wq->task_list here! * list_add(wq->task_list, q->task_list) spin_unlock(q->lock); *fetch old value of gp_flags here * spin_unlock(rnp_root) rcu_gp_kthread_wake() { swake_up(wq) { swait_active(wq) { list_empty(wq->task_list) } * return false *if (condition) * false * schedule();In this case, a wakeup is missed, which could cause the
rcu_gp_kthreadwaits for a long time.The reason of this is that we do a lockless
swait_active()check inswake_up(). To fix this, we can either 1) add asmp_mb()inswake_up()beforeswait_active()to provide the proper order or 2) simply remove theswait_active()inswake_up().The solution 2 not only fixes this problem but also keeps the swait and wait API as close as possible, as
wake_up()doesn't provide a full barrier and doesn't do a lockless check of the wait queue either. Moreover, there are users already usingswait_active()to do their quick checks for the wait queues, so it make less sense thatswake_up()andswake_up_all()do this on their own.This patch then removes the lockless
swait_active()check inswake_up()andswake_up_all().Reported-by Steven Rostedt <[email protected]>Signed-off-by Boqun Feng <[email protected]>Acked-by Paul E. McKenney <[email protected]>Tested-by Paul E. McKenney <[email protected]>
Quoted 5 lines
Quoted 3 lines
Hearing no objections but not hearing anything else, either, I have queued this for v4.14. If someone else would rather queue it, please let me know.
I have it too. Lets see who can get it into -tip first :-)
Heh! We could use it as a test of Ingo's handling of multiple identical patches. ;-)
Thanx, Paul