From: Jason Wang <jasowang@redhat.com>
To: Al Viro <viro@zeniv.linux.org.uk>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
Date: Wed, 3 Jun 2020 11:57:11 +0800 [thread overview]
Message-ID: <3358ae96-abb6-6be9-346a-0e971cb84dcd@redhat.com> (raw)
In-Reply-To: <20200603014815.GR23230@ZenIV.linux.org.uk>
On 2020/6/3 上午9:48, Al Viro wrote:
> On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
>> So vhost needs to poke at userspace *a lot* in a quick succession. It
>> is thus benefitial to enable userspace access, do our thing, then
>> disable. Except access_ok has already been pre-validated with all the
>> relevant nospec checks, so we don't need that. Add an API to allow
>> userspace access after access_ok and barrier_nospec are done.
> BTW, what are you going to do about vq->iotlb != NULL case? Because
> you sure as hell do *NOT* want e.g. translate_desc() under STAC.
> Disable it around the calls of translate_desc()?
translate_desc() itself doesn't do userspace access, so the idea is
probably disabling STAC around a batch of vhost_get_uesr()/vhost_put_user().
>
> How widely do you hope to stretch the user_access areas, anyway?
To have best performance for small packets like 64B, if possible, we
want to disable STAC not only for the metadata access done by vhost
accessors but also the data access via iov iterator.
>
> BTW, speaking of possible annotations: looks like there's a large
> subset of call graph that can be reached only from vhost_worker()
> or from several ioctls, with all uaccess limited to that subgraph
> (thankfully). Having that explicitly marked might be a good idea...
>
> Unrelated question, while we are at it: is there any point having
> vhost_get_user() a polymorphic macro? In all callers the third
> argument is __virtio16 __user * and the second one is an explicit
> *<something> where <something> is __virtio16 *. Similar for
> vhost_put_user(): in all callers the third arugment is
> __virtio16 __user * and the second - cpu_to_vhost16(vq, something).
This is because all virtqueue metadata that needs to be accessed
atomically is __virtio16 now, but this may not be true for future virtio
extension.
>
> Incidentally, who had come up with the name __vhost_get_user?
> Makes for lovey WTF moment for readers - esp. in vhost_put_user()...
I think the confusion comes since it does not accept userspace pointer
(when IOTLB is enabled).
How about renaming it as vhost_read()/vhost_write() ?
Thanks
>
next prev parent reply other threads:[~2020-06-03 3:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-02 8:45 Michael S. Tsirkin
2020-06-02 10:15 ` Jason Wang
2020-06-02 16:33 ` Al Viro
2020-06-02 17:18 ` Linus Torvalds
2020-06-02 17:44 ` Al Viro
2020-06-02 17:46 ` Al Viro
2020-06-02 20:32 ` Michael S. Tsirkin
2020-06-02 20:41 ` David Laight
2020-06-02 21:58 ` Al Viro
2020-06-03 8:08 ` David Laight
2020-06-02 20:43 ` Linus Torvalds
2020-06-03 6:01 ` Michael S. Tsirkin
[not found] ` <CAHk-=wi3=QuD30fRq8fYYTj9WmkgeZ0VR_Sh3DQHU+nmwj-jMg@mail.gmail.com>
2020-06-03 16:59 ` Linus Torvalds
2020-06-02 16:30 ` Al Viro
2020-06-02 20:42 ` Michael S. Tsirkin
2020-06-02 22:10 ` Al Viro
2020-06-03 5:17 ` Michael S. Tsirkin
2020-06-03 1:48 ` Al Viro
2020-06-03 3:57 ` Jason Wang [this message]
2020-06-03 4:18 ` Al Viro
2020-06-03 5:18 ` Jason Wang
2020-06-03 5:46 ` Michael S. Tsirkin
2020-06-03 6:23 ` Jason Wang
2020-06-03 6:30 ` Michael S. Tsirkin
2020-06-03 6:36 ` Jason Wang
2020-06-04 16:49 ` Michael S. Tsirkin
2020-06-05 10:03 ` Jason Wang
2020-06-06 20:08 ` Michael S. Tsirkin
2020-06-03 6:25 ` Michael S. Tsirkin
2020-06-03 5:29 ` Michael S. Tsirkin
2020-06-03 16:52 ` Al Viro
2020-06-04 6:10 ` Jason Wang
2020-06-04 14:59 ` Al Viro
2020-06-04 16:46 ` Michael S. Tsirkin
2020-06-04 10:10 ` Michael S. Tsirkin
2020-06-04 15:03 ` Al Viro
2020-06-04 16:47 ` Michael S. Tsirkin
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=3358ae96-abb6-6be9-346a-0e971cb84dcd@redhat.com \
--to=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®