2023-03-01 23:23:37

by Jakob Koschel

Subject: [PATCH] workqueue: avoid usage of list iterator after loop in __flush_workqueue()

If the list_for_each_entry_safe() iteration never breaks, 'next' would
contain an invalid pointer past the iterator loop. To ensure 'next' is
always valid, we only set it if the correct element was found. That
allows adding a WARN_ON_ONCE in case the code works incorrectly,
exposing currently undetectable potential bugs.

Additionally, Linus proposed to avoid any use of the list iterator
variable after the loop, in the attempt to move the list iterator
variable declaration into the macro to avoid any potential misuse after
the loop [1].

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1]
Signed-off-by: Jakob Koschel <[email protected]>
---
kernel/workqueue.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index b8b541caed48..73aff7b42903 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2982,14 +2982,16 @@ void __flush_workqueue(struct workqueue_struct *wq)
WARN_ON_ONCE(wq->flush_color != this_flusher.flush_color);

while (true) {
- struct wq_flusher *next, *tmp;
+ struct wq_flusher *next = NULL, *iter, *tmp;

/* complete all the flushers sharing the current flush color */
- list_for_each_entry_safe(next, tmp, &wq->flusher_queue, list) {
- if (next->flush_color != wq->flush_color)
+ list_for_each_entry_safe(iter, tmp, &wq->flusher_queue, list) {
+ if (iter->flush_color != wq->flush_color) {
+ next = iter;
break;
- list_del_init(&next->list);
- complete(&next->done);
+ }
+ list_del_init(&iter->list);
+ complete(&iter->done);
}

WARN_ON_ONCE(!list_empty(&wq->flusher_overflow) &&
@@ -3006,8 +3008,8 @@ void __flush_workqueue(struct workqueue_struct *wq)
* flusher_queue. This is the start-to-wait
* phase for these overflowed flushers.
*/
- list_for_each_entry(tmp, &wq->flusher_overflow, list)
- tmp->flush_color = wq->work_color;
+ list_for_each_entry(iter, &wq->flusher_overflow, list)
+ iter->flush_color = wq->work_color;

wq->work_color = work_next_color(wq->work_color);

@@ -3025,6 +3027,7 @@ void __flush_workqueue(struct workqueue_struct *wq)
* Need to flush more colors. Make the next flusher
* the new first flusher and arm pwqs.
*/
+ WARN_ON_ONCE(!next);
WARN_ON_ONCE(wq->flush_color == wq->work_color);
WARN_ON_ONCE(wq->flush_color != next->flush_color);


---
base-commit: c0927a7a5391f7d8e593e5e50ead7505a23cadf9
change-id: 20230302-workqueue-avoid-iter-after-loop-9d26db48654c

Best regards,
--
Jakob Koschel <[email protected]>

2023-03-02 03:08:33

by Lai Jiangshan

Subject: Re: [PATCH] workqueue: avoid usage of list iterator after loop in __flush_workqueue()

On Thu, Mar 2, 2023 at 7:23 AM Jakob Koschel <[email protected]> wrote:
>
> If the list_for_each_entry_safe() iteration never breaks, 'next' would
> contain an invalid pointer past the iterator loop. To ensure 'next' is
> always valid, we only set it if the correct element was found. That
> allows adding a WARN_ON_ONCE in case the code works incorrectly,
> exposing currently undetectable potential bugs.

Hello

In the code, if I did not miss anything important, I don't think there are any
way that the 'next' is invalid because it is used after this check:
if (list_empty(&wq->flusher_queue))

which means the list_for_each_entry_safe() iteration did break and
the 'next' is valid.
(the code also moves entries from &wq->flusher_overflow to
wq->flusher_queue, but it only happens when wq->flusher_queue
is not empty because the number of colors > 2)

The logic is quite complicated and I agree with you that we
should avoid using the 'next' after the loop directly and remove
any possible misunderstanding/confusion.

But I don't want to make the code even more complicated by
adding more variables.

I prefer reinitializing the "next" before it is reused as:
next = list_first_entry(&wq->flusher_queue, struct wq_flusher, list);

Thanks
Lai