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)) {
return __vsock_recvmsg(sk, msg, len, flags);release_sock(sk);
- }
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