[PATCH net-next] vhost: use "checked" versions of get_user() and put_user()

[Arnd Bergmann]

On Wed, Nov 26, 2025, at 20:47, Jon Kohler wrote:
>> On Nov 26, 2025, at 5:25 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wed, Nov 26, 2025, at 07:04, Jason Wang wrote:
>>> On Wed, Nov 26, 2025 at 3:45 AM Jon Kohler <jon at nutanix.com> wrote:
>> I think the more relevant commit is for 64-bit Arm here, but this does
>> the same thing, see 84624087dd7e ("arm64: uaccess: Don't bother
>> eliding access_ok checks in __{get, put}_user").
>
> Ah! Right, this is definitely the important bit, as it makes it
> crystal clear that these are exactly the same thing. The current
> code is:
> #define get_user	__get_user
> #define put_user	__put_user
>
> So, this patch changing from __* to regular versions is a no-op
> on arm side of the house, yea?

Certainly on 64-bit, and almost always on 32-bit, yes.

>> I would think that if we change the __get_user() to get_user()
>> in this driver, the same should be done for the
>> __copy_{from,to}_user(), which similarly skips the access_ok()
>> check but not the PAN/SMAP handling.
>
> Perhaps, thats a good call out. I’d file that under one battle
> at a time. Let’s get get/put user dusted first, then go down
> that road?

It depends on what your bigger plan is. Are you working on
improving the vhost driver specifically, or are you trying
to kill off the __get_user/__put_user calls across the
entire kernel?

In the latter case, I would suggest you do one driver
at a time but address access_ok(), __{get,put}_user and
__copy_{from,to}_user() with a single patch per driver
as long as this is simple enough. For vhost specifically,
doing it piecemeal is probably fine since the interaction
is more complicated than most others.

>> In general, the access_ok()/__get_user()/__copy_from_user()
>> pattern isn't really helpful any more, as Linus already
>> explained. I can't tell from the vhost driver code whether
>> we can just drop the access_ok() here and use the plain
>> get_user()/copy_from_user(), or if it makes sense to move
>> to the newer user_access_begin()/unsafe_get_user()/
>> unsafe_copy_from_user()/user_access_end() and try optimize
>> out a few PAN/SMAP flips in the process.
>
> In general, I think there are a few spots where we might be
> able to optimize (vhost_get_vq_desc perhaps?) as that gets
> called quite a bit and IIRC there are at least two flips
> in there that perhaps we could elide to one? An investigation
> for another day I think.

Yes, sounds good.

      Arnd