On 12/23/25 14:15, Stefano Garzarella wrote:
> On Tue, Dec 23, 2025 at 12:09:51PM +0100, Michal Luczaj wrote:
>> On 12/23/25 11:26, Stefano Garzarella wrote:
>>> On Tue, Dec 23, 2025 at 10:15:28AM +0100, Michal Luczaj wrote:
>> ...
>>>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>>>> index adcba1b7bf74..c093db8fec2d 100644
>>>> --- a/net/vmw_vsock/af_vsock.c
>>>> +++ b/net/vmw_vsock/af_vsock.c
>>>> @@ -1787,6 +1787,7 @@ static int vsock_accept(struct socket *sock, struct
>>>> socket *newsock,
>>>> } else {
>>>> newsock->state = SS_CONNECTED;
>>>> sock_graft(connected, newsock);
>>>> + set_bit(SOCK_CUSTOM_SOCKOPT, &newsock->flags);
>>>
>>> I was a bit confused about next lines calling set_bit on
>>> `connected->sk_socket->flags`, but after `sock_graft(connected,
>>> newsock)` they are equivalent.
>>>
>>> So, maybe I would move the new line before the sock_graft() call or use
>>> `connected->sk_socket->flags` if you want to keep it after it.
>> ...
>>>> if (vsock_msgzerocopy_allow(vconnected->transport))
>>>> set_bit(SOCK_SUPPORT_ZC,
>>>> &connected->sk_socket->flags);
>>
>> Hmm, isn't using both `connected->sk_socket->flags` and `newsock->flags` a
>> bit confusing?
>
> Yep, for that reason I suggested to use `connected->sk_socket->flags`.
>
>> `connected->sk_socket->flags` feels unnecessary long to me.
>> So how about a not-so-minimal-patch to have
>>
>> newsock->state = SS_CONNECTED;
>> set_bit(SOCK_CUSTOM_SOCKOPT, &newsock->flags);
>> if (vsock_msgzerocopy_allow(vconnected->transport))
>> set_bit(SOCK_SUPPORT_ZC, &newsock->flags);
>> sock_graft(connected, newsock);
>
> No, please, this is a fix, so let's touch less as possible.
>
> As I mentioned before, we have 2 options IMO:
> 1. use `set_bit(SOCK_CUSTOM_SOCKOPT, &newsock->flags);` but move it
> before `sock_graft()`
> 2. use `connected->sk_socket->flags` and set it after `sock_graft()` if
> we want to be a bit more consistent
>
> I'd go with option 2, because I like to be consistent and it's less
> confusing IMHO, but I'm fine also with option 1.
Yeah, all right, here it is:
https://lore.kernel.org/netdev/20251229-vsock-child-sock-custom-sockopt-v2-0-64778d6c4...@rbox.co/
Thanks,
Michal
