From: Michal Luczaj <mhal@rbox.co>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC net v2 3/3] vsock: Fix IOCTL_VM_SOCKETS_GET_LOCAL_CID to check also `transport_local`
Date: Wed, 25 Jun 2025 23:23:54 +0200 [thread overview]
Message-ID: <0adde2db-3a75-4ade-a1c8-8c3bc2a0b1fd@rbox.co> (raw)
In-Reply-To: <uqap2qzmvkfqxfqssxnt5anni6jhdupnarriinblznv5lfk764@qkrjq22xeygb>
On 6/25/25 10:54, Stefano Garzarella wrote:
> On Fri, Jun 20, 2025 at 09:52:45PM +0200, Michal Luczaj wrote:
>> Support returning VMADDR_CID_LOCAL in case no other vsock transport is
>> available.
>>
>> Fixes: 0e12190578d0 ("vsock: add local transport support in the vsock core")
>> Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>> Signed-off-by: Michal Luczaj <mhal@rbox.co>
>> ---
>> man vsock(7) mentions IOCTL_VM_SOCKETS_GET_LOCAL_CID vs. VMADDR_CID_LOCAL:
>>
>> Ioctls
>> ...
>> IOCTL_VM_SOCKETS_GET_LOCAL_CID
>> ...
>> Consider using VMADDR_CID_ANY when binding instead of
>> getting the local CID with IOCTL_VM_SOCKETS_GET_LOCAL_CID.
>>
>> Local communication
>> ....
>> The local CID obtained with IOCTL_VM_SOCKETS_GET_LOCAL_CID can be
>> used for the same purpose, but it is preferable to use
>> VMADDR_CID_LOCAL.
>>
>> I was wondering it that would need some rewriting, since we're adding
>> VMADDR_CID_LOCAL as a possible ioctl's return value.
>
> IIRC the reason was, that if we have for example a G2H module loaded,
> the ioctl returns the CID of that module (e.g. 42). So, we can use both
> 42 and VMADDR_CID_LOCAL to do the loopback communication, but we
> encourage to always use VMADDR_CID_LOCAL. With this change we basically
> don't change that, but we change the fact that if there is only the
> loopback module loaded, before the ioctl returned VMADDR_CID_ANY, while
> now it returns LOCAL rightly.
>
> So, IMO we are fine.
All right, got it.
>> ---
>> net/vmw_vsock/af_vsock.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>> index a1b1073a2c89f865fcdb58b38d8e7feffcf1544f..4bdb4016bd14d790f3d217d5063be64a1553b194 100644
>> --- a/net/vmw_vsock/af_vsock.c
>> +++ b/net/vmw_vsock/af_vsock.c
>> @@ -2577,6 +2577,8 @@ static long vsock_dev_do_ioctl(struct file *filp,
>> cid = vsock_transport_local_cid(&transport_g2h);
>> if (cid == VMADDR_CID_ANY)
>> cid = vsock_transport_local_cid(&transport_h2g);
>> + if (cid == VMADDR_CID_ANY && transport_local)
>> + cid = VMADDR_CID_LOCAL;
>
> why not `cid = vsock_transport_local_cid(&transport_local)` like for
> H2G?
Sure, can do. I've assumed transport_local would always have a local CID of
VMADDR_CID_LOCAL. So taking mutex and going through a callback function to
get VMADDR_CID_LOCAL seemed superfluous. But I get it, if you want to have
it symmetrical with the other vsock_transport_local_cid()s.
Thanks,
Michal
next prev parent reply other threads:[~2025-06-25 21:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 19:52 [PATCH RFC net v2 0/3] vsock: Fix transport_{h2g,g2h,dgram,local} TOCTOU issues Michal Luczaj
2025-06-20 19:52 ` [PATCH RFC net v2 1/3] vsock: Fix transport_{g2h,h2g} TOCTOU Michal Luczaj
2025-06-25 8:43 ` Stefano Garzarella
2025-06-25 21:23 ` Michal Luczaj
2025-06-27 8:02 ` Stefano Garzarella
2025-06-29 21:26 ` Michal Luczaj
2025-06-30 9:05 ` Stefano Garzarella
2025-06-30 11:02 ` Michal Luczaj
2025-07-01 10:34 ` Stefano Garzarella
2025-07-02 13:44 ` Michal Luczaj
2025-06-20 19:52 ` [PATCH RFC net v2 2/3] vsock: Fix transport_* TOCTOU Michal Luczaj
2025-06-25 8:46 ` Stefano Garzarella
2025-06-27 8:08 ` Stefano Garzarella
2025-06-29 21:26 ` Michal Luczaj
2025-06-30 9:47 ` Stefano Garzarella
2025-06-20 19:52 ` [PATCH RFC net v2 3/3] vsock: Fix IOCTL_VM_SOCKETS_GET_LOCAL_CID to check also `transport_local` Michal Luczaj
2025-06-25 8:54 ` Stefano Garzarella
2025-06-25 21:23 ` Michal Luczaj [this message]
2025-06-27 8:10 ` Stefano Garzarella
2025-06-29 21:26 ` Michal Luczaj
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=0adde2db-3a75-4ade-a1c8-8c3bc2a0b1fd@rbox.co \
--to=mhal@rbox.co \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
/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®