From: Jens Axboe <[email protected]>
To: Breno Leitao <[email protected]>,
Pavel Begunkov <[email protected]>
Cc: [email protected], "open list:IO_URING" <[email protected]>,
open list <[email protected]>
Subject: Re: [PATCH] io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
Date: Fri, 3 May 2024 12:32:38 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 5/3/24 11:37 AM, Breno Leitao wrote:
> Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
> to address potential data races.
>
> The structure io_worker->flags may be accessed through parallel data
> paths, leading to concurrency issues. When KCSAN is enabled, it reveals
> data races occurring in io_worker_handle_work and
> io_wq_activate_free_worker functions.
>
> BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
> write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
> io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
> io_wq_worker (io_uring/io-wq.c:?)
> <snip>
>
> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
> io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
> io_wq_enqueue (io_uring/io-wq.c:947)
> io_queue_iowq (io_uring/io_uring.c:524)
> io_req_task_submit (io_uring/io_uring.c:1511)
> io_handle_tw_list (io_uring/io_uring.c:1198)
>
> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
> git://git.kernel.org/pub/scm/virt/kvm/kvm").
>
> These races involve writes and reads to the same memory location by
> different tasks running on different CPUs. To mitigate this, refactor
> the code to use atomic operations such as set_bit(), test_bit(), and
> clear_bit() instead of basic "and" and "or" operations. This ensures
> thread-safe manipulation of worker flags.
Looks good, a few comments for v2:
> diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c
> index 522196dfb0ff..6712d70d1f18 100644
> --- a/io_uring/io-wq.c
> +++ b/io_uring/io-wq.c
> @@ -44,7 +44,7 @@ enum {
> */
> struct io_worker {
> refcount_t ref;
> - unsigned flags;
> + unsigned long flags;
> struct hlist_nulls_node nulls_node;
> struct list_head all_list;
> struct task_struct *task;
This now creates a hole in the struct, maybe move 'lock' up after ref so
that it gets filled and the current hole after 'lock' gets removed as
well?
And then I'd renumber the flags, they take bit offsets, not
masks/values. Otherwise it's a bit confusing for someone reading the
code, using masks with test/set bit functions.
--
Jens Axboe
next prev parent reply other threads:[~2024-05-03 18:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 17:37 [PATCH] io_uring/io-wq: Use set_bit() and test_bit() at worker->flags Breno Leitao
2024-05-03 18:32 ` Jens Axboe [this message]
2024-05-07 10:44 ` Breno Leitao
2024-05-07 11:02 ` Breno Leitao
2024-05-07 13:28 ` Jens Axboe
2024-05-03 18:41 ` Jens Axboe
2024-05-03 19:24 ` Christophe JAILLET
2024-05-03 19:36 ` Jens Axboe
2024-05-07 9:24 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox