From: Linus Torvalds <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring <[email protected]>
Subject: Re: [GIT PULL] io_uring fixes for 5.12-rc2
Date: Sat, 6 Mar 2021 13:14:14 -0800 [thread overview]
Message-ID: <CAHk-=wg_D4Mobaj9mff2PEy+Qm67kGTP3kxo2=Aoa_UTc1k-_A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
On Sat, Mar 6, 2021 at 8:25 AM Jens Axboe <[email protected]> wrote:
>
> You're not, but creds is just one part of it. But I think we're OK
> saying "If you do unshare(CLONE_FILES) or CLONE_FS, then it's not
> going to impact async offload for your io_uring". IOW, you really
> should do that before setting up your ring(s).
Yeah, I think that one is solidly in a "don't do that then" thing.
Changing credentials is "normal use" - if you are a server process,
you may want to just make sure that you use different credentials for
different client requests etc.
But doing something like "I set up an io_uring for async work, and
then I dis-associated from my existing FS state entirely", that's not
normal. That's just a "you did something crazy, and you'll get crazy
results back, because the async part is fundamentally different from
the synchronous part".
It might be an option to just tear down the IO uring state entirely if
somebody does a "unshare(CLONE_FILES)", the same way unsharing the VM
(ie execve) does. But then it shouldn't even try to keep the state in
sync, it would just be "ok, your old io_uring is now simply gone".
I'm not sure it's even worth worrying about. Because at some point,
it's just "garbage in, garbage out".
Linus
next prev parent reply other threads:[~2021-03-06 21:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 18:09 [GIT PULL] io_uring fixes for 5.12-rc2 Jens Axboe
2021-03-05 20:54 ` Linus Torvalds
2021-03-05 21:58 ` Jens Axboe
2021-03-05 23:03 ` Linus Torvalds
2021-03-06 16:25 ` Jens Axboe
2021-03-06 21:14 ` Linus Torvalds [this message]
2021-03-06 22:28 ` Jens Axboe
2021-03-05 21:58 ` pr-tracker-bot
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-=wg_D4Mobaj9mff2PEy+Qm67kGTP3kxo2=Aoa_UTc1k-_A@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