On 3/19/25 10:34, Stefano Garzarella wrote:
> On Mon, Mar 17, 2025 at 10:52:25AM +0100, Michal Luczaj wrote:
>> ...
>> -static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
>> - size_t len, int flags, int *addr_len)
>> +static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t
>> len,
>> + int flags, int *addr_len)
>
> I would avoid this change, especially in a patch with the Fixes tag then
> to be backported.
I thought that since I've modified this function in so many places, doing
this wouldn't hurt. But ok, I'll drop this change.
>> {
>> struct sk_psock *psock;
>> struct vsock_sock *vsk;
>> int copied;
>>
>> + /* Since signal delivery during connect() may reset the state of socket
>> + * that's already in a sockmap, take the lock before checking on psock.
>> + * This serializes a possible transport reassignment, protecting this
>> + * function from running with NULL transport.
>> + */
>> + lock_sock(sk);
>> +
>> psock = sk_psock_get(sk);
>> - if (unlikely(!psock))
>> + if (unlikely(!psock)) {
>> + release_sock(sk);
>> return __vsock_recvmsg(sk, msg, len, flags);
>> + }
>>
>> - lock_sock(sk);
>> vsk = vsock_sk(sk);
>> -
>> if (WARN_ON_ONCE(!vsk->transport)) {
>> copied = -ENODEV;
>> goto out;
>> }
>>
>> if (vsock_has_data(sk, psock) && sk_psock_queue_empty(psock)) {
>> - release_sock(sk);
>> sk_psock_put(sk, psock);
>> + release_sock(sk);
>
> But here we release it, so can still a reset happen at this point,
> before calling __vsock_connectible_recvmsg().
> In there anyway we handle the case where transport is null, so there's
> no problem, right?
Yes, I think we're good. That function needs to gracefully handle being
called without a transport, and it does.
Thanks,
Michal
