From: Pavel Begunkov <[email protected]>
To: Stefan Metzmacher <[email protected]>, Jens Axboe <[email protected]>,
Daurnimator <[email protected]>
Cc: [email protected]
Subject: Re: [PATCHSET 0/4] Add support for shared io-wq backends
Date: Tue, 28 Jan 2020 13:30:26 +0300 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 1/28/2020 1:01 PM, Stefan Metzmacher wrote:
>>>>>>> OK, so how about this:
>>>>>>>
>>>>>>> - We use the 'fd' as the lookup key. This makes it easy since we can
>>>>>>> just check if it's a io_uring instance or not, we don't need to do any
>>>>>>> tracking on the side. It also means that the application asking for
>>>>>>> sharing must already have some relationship to the process that
>>>>>>> created the ring.
>>>>>>>
>>>>>>> - mm/creds must be transferred through the work item. Any SQE done on
>>>>>>> behalf of io_uring_enter() directly already has that, if punted we
>>>>>>> must pass the creds and mm. This means we break the static setup of
>>>>>>> io_wq->mm/creds. It also means that we probably have to add that to
>>>>>>> io_wq_work, which kind of sucks, but...
>>>>>> It'd fix Stefan's worry too.
>>>>>>
>>>>>>> I think with that we have a decent setup, that's also safe. I've dropped
>>>>>>> the sharing patches for now, from the 5.6 tree.
>>>>>>
>>>>>> So one concern might be SQPOLL, it'll have to use the ctx creds and mm
>>>>>> as usual. I guess that is ok.
>>
>> https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs-wq
>>
>> Top patch there is the mm/creds passing. I kind of like it even if it
>> means we're growing io_wq_worker (and subsequently io_kiocb) by 16
>> bytes, as it means we can be more flexible. This solves it for this use
>> case, but also the case that Stefan was worried about.
>
> Ok, that means that ctx->creds is only used in the IORING_SETUP_SQPOLL
> case and there it's used for all requests as get_current_cred() is the
> same as ctx->creds from within io_sq_thread(), correct?
Right
> And in all other cases get_current_cred() is used at io_uring_enter() time.
Exactly
> That's good in order to make the behavior consistent again and prevents
> potential random security problems.
BTW, there also can be problems with registered resources. E.g. for
buffers io_uring can get_user_pages() of one process, and then use the
pages from another process by passing a buffer index. This is not as
bad, however.
>
> BTW: you need to revert/drop 44d282796f81eb1debc1d7cb53245b4cb3214cb5
> in that branch. Or just rebase on v5.5 final?
>
> Thanks!
> metze
>
--
Pavel Begunkov
next prev parent reply other threads:[~2020-01-28 10:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 23:16 [PATCHSET 0/4] Add support for shared io-wq backends Jens Axboe
2020-01-23 23:16 ` [PATCH 1/4] io-wq: make the io_wq ref counted Jens Axboe
2020-01-23 23:16 ` [PATCH 2/4] io-wq: add 'id' to io_wq Jens Axboe
2020-01-23 23:16 ` [PATCH 3/4] io-wq: allow lookup of existing io_wq with given id Jens Axboe
2020-01-24 9:54 ` Stefan Metzmacher
2020-01-24 16:41 ` Jens Axboe
2020-01-23 23:16 ` [PATCH 4/4] io_uring: add support for sharing kernel io-wq workqueue Jens Axboe
2020-01-24 9:51 ` [PATCHSET 0/4] Add support for shared io-wq backends Stefan Metzmacher
2020-01-24 16:43 ` Jens Axboe
2020-01-24 19:14 ` Stefan Metzmacher
2020-01-24 21:37 ` Jens Axboe
2020-01-24 20:34 ` Pavel Begunkov
2020-01-24 21:38 ` Jens Axboe
2020-01-26 1:51 ` Daurnimator
2020-01-26 15:11 ` Pavel Begunkov
2020-01-26 17:00 ` Jens Axboe
2020-01-27 13:29 ` Pavel Begunkov
2020-01-27 13:39 ` Jens Axboe
2020-01-27 14:07 ` Pavel Begunkov
2020-01-27 19:39 ` Pavel Begunkov
2020-01-27 19:45 ` Jens Axboe
2020-01-27 20:33 ` Jens Axboe
2020-01-27 21:45 ` Pavel Begunkov
2020-01-27 22:40 ` Jens Axboe
2020-01-27 23:00 ` Jens Axboe
2020-01-27 23:17 ` Pavel Begunkov
2020-01-27 23:23 ` Jens Axboe
2020-01-27 23:25 ` Pavel Begunkov
2020-01-27 23:38 ` Jens Axboe
2020-01-28 10:01 ` Stefan Metzmacher
2020-01-28 10:30 ` Pavel Begunkov [this message]
2020-01-28 10:35 ` Stefan Metzmacher
2020-01-28 10:51 ` Pavel Begunkov
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] \
/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