From: Linus Torvalds <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring <[email protected]>
Subject: Re: [GIT PULL] io_uring thread worker change
Date: Fri, 26 Feb 2021 18:48:11 -0800 [thread overview]
Message-ID: <CAHk-=wjWB3+NnWwuwyQofNv=d1kT0j7T6QH-G_yF_fBO52yvag@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
Reading through this once..
I'll read through it another time tomorrow before merging it, but on
the whole it looks good. The concept certainly is the right now, but I
have a few questions about some of the details..
On Fri, Feb 26, 2021 at 2:04 PM Jens Axboe <[email protected]> wrote:
>
> io-wq: fix races around manager/worker creation and task exit
Where did that
+ __set_current_state(TASK_RUNNING);
in the patch come from? That looks odd.
Is it because io_wq_manager() does a
set_current_state(TASK_INTERRUPTIBLE);
at one point? Regardless, that code looks very very strange.
> io_uring: remove the need for relying on an io-wq fallback worker
This is coded really oddly.
+ do {
+ head = NULL;
+ work = READ_ONCE(ctx->exit_task_work);
+ } while (cmpxchg(&ctx->exit_task_work, work, head) != work);
Whaa?
If you want to write
work = xchg(&ctx->exit_task_work, NULL);
then just do that. Instead of an insane cmpxchg loop that isn't even
well-written.
I say that it isn't even well-written, because when you really do want
a cmpxchg loop, then realize that cmpxchg() returns the old value, so
the proper way to write it is
new = whatever;
expect = READ_ONCE(ctx->exit_task_work);
for (;;) {
new->next = expect; // Mumble mumble - this is why you want
the cmpxchg
was = cmpxchg(&ctx->exit_task_work, expect, new);
if (was == expect)
break;
expect = was;
}
IOW, that READ_ONCE() of the old value should happen only once - and
isn't worth a READ_ONCE() in the first place. There's nothing "read
once" about it.
But as mentioned, if all you want is an atomic "get and replace with
NULL", then just a plain "xchg()" is what you should do.
Yes, that cmpxchg loop _works_, but it is really confusing to read
that way, when clearly you don't actually need or really want a
cmpxchg.
(The other cmpxchg loop in the same patch is needed, but does that
unnecessary "re-read the value that cmpxchg just returned").
Please explain.
Linus
next prev parent reply other threads:[~2021-02-27 2:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 22:04 [GIT PULL] io_uring thread worker change Jens Axboe
2021-02-27 2:48 ` Linus Torvalds [this message]
2021-02-27 4:27 ` Jens Axboe
2021-02-27 16:38 ` Linus Torvalds
2021-02-27 19:47 ` Jens Axboe
2021-02-27 16:41 ` pr-tracker-bot
2021-03-11 10:43 ` Backporting to stable... " Stefan Metzmacher
2021-03-11 18:46 ` Jens Axboe
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 \
--in-reply-to='CAHk-=wjWB3+NnWwuwyQofNv=d1kT0j7T6QH-G_yF_fBO52yvag@mail.gmail.com' \
[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