* [PATCH] sched/swait: Reduce lock contention in swake_up_all
@ 2026-05-05 9:04 lirongqing
2026-05-05 16:05 ` K Prateek Nayak
0 siblings, 1 reply; 3+ messages in thread
From: lirongqing @ 2026-05-05 9:04 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
The entire task list have been moved a local list under the lock,
it is unnecessary to hold the lock to wake tasks, This reduces lock
operations from O(n) to O(1).
Move list_del_init before wake_up_state to prevent potential
use-after-free if the woken task exits immediately and releases
its memory.
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
kernel/sched/swait.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
index 0fef649..ee4e658 100644
--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -66,19 +66,13 @@ void swake_up_all(struct swait_queue_head *q)
raw_spin_lock_irq(&q->lock);
list_splice_init(&q->task_list, &tmp);
+ raw_spin_unlock_irq(&q->lock);
while (!list_empty(&tmp)) {
curr = list_first_entry(&tmp, typeof(*curr), task_list);
- wake_up_state(curr->task, TASK_NORMAL);
list_del_init(&curr->task_list);
-
- if (list_empty(&tmp))
- break;
-
- raw_spin_unlock_irq(&q->lock);
- raw_spin_lock_irq(&q->lock);
+ wake_up_state(curr->task, TASK_NORMAL);
}
- raw_spin_unlock_irq(&q->lock);
}
EXPORT_SYMBOL(swake_up_all);
--
2.9.4
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] sched/swait: Reduce lock contention in swake_up_all
2026-05-05 9:04 [PATCH] sched/swait: Reduce lock contention in swake_up_all lirongqing
@ 2026-05-05 16:05 ` K Prateek Nayak
2026-05-06 9:27 ` 答复: [外部邮件] " Li,Rongqing(ACG CCN)
0 siblings, 1 reply; 3+ messages in thread
From: K Prateek Nayak @ 2026-05-05 16:05 UTC (permalink / raw)
To: lirongqing, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, linux-kernel
Hello Li,
On 5/5/2026 2:34 PM, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> The entire task list have been moved a local list under the lock,
> it is unnecessary to hold the lock to wake tasks, This reduces lock
> operations from O(n) to O(1).
>
> Move list_del_init before wake_up_state to prevent potential
> use-after-free if the woken task exits immediately and releases
> its memory.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> kernel/sched/swait.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
> index 0fef649..ee4e658 100644
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -66,19 +66,13 @@ void swake_up_all(struct swait_queue_head *q)
>
> raw_spin_lock_irq(&q->lock);
> list_splice_init(&q->task_list, &tmp);
> + raw_spin_unlock_irq(&q->lock);
> while (!list_empty(&tmp)) {
> curr = list_first_entry(&tmp, typeof(*curr), task_list);
>
> - wake_up_state(curr->task, TASK_NORMAL);
> list_del_init(&curr->task_list);
> -
> - if (list_empty(&tmp))
> - break;
> -
> - raw_spin_unlock_irq(&q->lock);
> - raw_spin_lock_irq(&q->lock);
> + wake_up_state(curr->task, TASK_NORMAL);
So I'm not fully convinced this is safe. Quick scenario I can think of
is:
CPU0: swake_up_all() CPU1: Signal task "curr"
==================== ========================
swake_up_all(q)
...
list_splice_init(&q->task_list, &tmp);
raw_spin_unlock_irq(&q->lock);
while (!list_empty(&tmp)) {
curr = ...; /* Task curr gets a signal */
======> Interrupted wake_up_task(curr) /* same as curr */
<====== curr switches in
finish_swait()
list_del_init(&curr->task_list)
__list_del_entry(&curr->task_list.prev, &curr->task_list.next)
next->prev = prev;
prev->next = next;
INIT_LIST_HEAD(&curr->task_list)
WRITE_ONCE(curr->task_list.next, &curr->task_list);
========> Interrupted
/*
* At this point curr->task_list, looks like:
*
* curr->task_list.next = &curr->task_list
* curr->task_list.prev = &tmp
*/
<===== Interrupt return
list_del_init(&curr->task_list);
__list_del_entry(&curr->task_list.prev, &curr->task_list.next)
next->prev = prev; /* Write &tmp back to curr->task_list.prev */
prev->next = next; /* Writes tmp's next as curr's list head */
INIT_LIST_HEAD(&curr->task_list)
WRITE_ONCE(curr->task_list.next, &curr->task_list);
WRITE_ONCE(curr->task_list.prev, &curr->task_list);
So at this point, your list looks like:
tmp: prev = /* tail of list */
next = &curr->task_list
curr->task_list: prev = &curr->task_list
next = &curr->task_list
actual_next: prev = &tmp
next = /* Next element */
...
which seems like a list corruption unless I'm missing something.
I think the wakeup can be done outside of the "&q->lock" but the
list removal, even on the tmp list, has to be synchronized by
&q->lock at the very least but I think there is some ordering
required wrt wakeup and the list removal.
I'll let others comment if there are more subtleties involved
wrt the task wakeup itself - perhaps there are cases where the
task wakes up, decides to wait in an exclusive mode for a
condition on another wake queue, then:
- New wake queue gets a swake_up_one() for the head.
- previous swake_up_all() finishes and wakes up this task.
- Both tasks see "condition" and begin running even though
they opted for exclusive wait and perhaps break some
assumption.
> }
> - raw_spin_unlock_irq(&q->lock);
> }
> EXPORT_SYMBOL(swake_up_all);
>
--
Thanks and Regards,
Prateek
^ permalink raw reply [flat|nested] 3+ messages in thread
* 答复: [外部邮件] Re: [PATCH] sched/swait: Reduce lock contention in swake_up_all
2026-05-05 16:05 ` K Prateek Nayak
@ 2026-05-06 9:27 ` Li,Rongqing(ACG CCN)
0 siblings, 0 replies; 3+ messages in thread
From: Li,Rongqing(ACG CCN) @ 2026-05-06 9:27 UTC (permalink / raw)
To: K Prateek Nayak, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, linux-kernel@vger.kernel.org
>
> Hello Li,
>
> On 5/5/2026 2:34 PM, lirongqing wrote:
> > From: Li RongQing <lirongqing@baidu.com>
> >
> > The entire task list have been moved a local list under the lock, it
> > is unnecessary to hold the lock to wake tasks, This reduces lock
> > operations from O(n) to O(1).
> >
> > Move list_del_init before wake_up_state to prevent potential
> > use-after-free if the woken task exits immediately and releases its
> > memory.
> >
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> > kernel/sched/swait.c | 10 ++--------
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c index
> > 0fef649..ee4e658 100644
> > --- a/kernel/sched/swait.c
> > +++ b/kernel/sched/swait.c
> > @@ -66,19 +66,13 @@ void swake_up_all(struct swait_queue_head *q)
> >
> > raw_spin_lock_irq(&q->lock);
> > list_splice_init(&q->task_list, &tmp);
> > + raw_spin_unlock_irq(&q->lock);
> > while (!list_empty(&tmp)) {
> > curr = list_first_entry(&tmp, typeof(*curr), task_list);
> >
> > - wake_up_state(curr->task, TASK_NORMAL);
> > list_del_init(&curr->task_list);
> > -
> > - if (list_empty(&tmp))
> > - break;
> > -
> > - raw_spin_unlock_irq(&q->lock);
> > - raw_spin_lock_irq(&q->lock);
> > + wake_up_state(curr->task, TASK_NORMAL);
>
> So I'm not fully convinced this is safe. Quick scenario I can think of
> is:
>
>
> CPU0: swake_up_all()
> CPU1: Signal task "curr"
> ====================
> ========================
>
> swake_up_all(q)
> ...
> list_splice_init(&q->task_list, &tmp);
> raw_spin_unlock_irq(&q->lock);
>
> while (!list_empty(&tmp)) {
> curr = ...;
> /* Task curr gets a signal */
> ======> Interrupted
> wake_up_task(curr) /* same as curr */
>
> <====== curr switches in
>
> finish_swait()
>
> list_del_init(&curr->task_list)
>
> __list_del_entry(&curr->task_list.prev, &curr->task_list.next)
>
> next->prev = prev;
>
> prev->next = next;
>
> INIT_LIST_HEAD(&curr->task_list)
>
> WRITE_ONCE(curr->task_list.next, &curr->task_list);
>
> ========> Interrupted
>
> /*
> * At this point curr->task_list, looks like:
> *
> * curr->task_list.next = &curr->task_list
> * curr->task_list.prev = &tmp
> */
>
> <===== Interrupt return
> list_del_init(&curr->task_list);
> __list_del_entry(&curr->task_list.prev, &curr->task_list.next)
> next->prev = prev; /* Write &tmp back to curr->task_list.prev */
> prev->next = next; /* Writes tmp's next as curr's list head */
> INIT_LIST_HEAD(&curr->task_list)
> WRITE_ONCE(curr->task_list.next, &curr->task_list);
> WRITE_ONCE(curr->task_list.prev, &curr->task_list);
>
>
> So at this point, your list looks like:
>
> tmp: prev = /* tail of list */
> next = &curr->task_list
>
> curr->task_list: prev = &curr->task_list
> next = &curr->task_list
>
> actual_next: prev = &tmp
> next = /* Next element */
>
> ...
>
> which seems like a list corruption unless I'm missing something.
>
> I think the wakeup can be done outside of the "&q->lock" but the list removal,
> even on the tmp list, has to be synchronized by &q->lock at the very least but I
> think there is some ordering required wrt wakeup and the list removal.
>
You are correct. The tmp list must be protected by &q->lock.
Since the lock is still required, The benefit of moving wake_up_state outside of spin lock maybe minimal.
Thanks
-Li
> I'll let others comment if there are more subtleties involved wrt the task wakeup
> itself - perhaps there are cases where the task wakes up, decides to wait in an
> exclusive mode for a condition on another wake queue, then:
>
> - New wake queue gets a swake_up_one() for the head.
> - previous swake_up_all() finishes and wakes up this task.
> - Both tasks see "condition" and begin running even though
> they opted for exclusive wait and perhaps break some
> assumption.
>
> > }
> > - raw_spin_unlock_irq(&q->lock);
> > }
> > EXPORT_SYMBOL(swake_up_all);
> >
>
> --
> Thanks and Regards,
> Prateek
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-06 9:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-05 9:04 [PATCH] sched/swait: Reduce lock contention in swake_up_all lirongqing
2026-05-05 16:05 ` K Prateek Nayak
2026-05-06 9:27 ` 答复: [外部邮件] " Li,Rongqing(ACG CCN)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox