search for: free_pkt

This series makes the credit mechanism implemented in the virtio-vsock devices more robust. Patch 1 sends an update to the remote peer when the buf_alloc change. Patch 2 prevents a malicious peer (especially the guest) can consume all the memory of the other peer, discarding packets when the credit available is not respected. Stefano Garzarella (2): vsock/virtio: send a credit update when

...->msg, len); if (err) goto out; @@ -842,24 +848,60 @@ virtio_transport_recv_connecting(struct sock *sk, return err; } +static void +virtio_transport_recv_enqueue(struct vsock_sock *vsk, + struct virtio_vsock_pkt *pkt) +{ + struct virtio_vsock_sock *vvs = vsk->trans; + bool free_pkt = false; + + pkt->len = le32_to_cpu(pkt->hdr.len); + pkt->off = 0; + + spin_lock_bh(&vvs->rx_lock); + + virtio_transport_inc_rx_pkt(vvs, pkt); + + /* Try to copy small packets into the buffer of last packet queued, + * to avoid wasting memory queueing the entire buffer with a small...

...->msg, len); if (err) goto out; @@ -841,24 +847,60 @@ virtio_transport_recv_connecting(struct sock *sk, return err; } +static void +virtio_transport_recv_enqueue(struct vsock_sock *vsk, + struct virtio_vsock_pkt *pkt) +{ + struct virtio_vsock_sock *vvs = vsk->trans; + bool free_pkt = false; + + pkt->len = le32_to_cpu(pkt->hdr.len); + pkt->off = 0; + + spin_lock_bh(&vvs->rx_lock); + + virtio_transport_inc_rx_pkt(vvs, pkt); + + /* Try to copy small packets into the buffer of last packet queued, + * to avoid wasting memory queueing the entire buffer with a small...

...-841,24 +847,60 @@ virtio_transport_recv_connecting(struct sock *sk, > return err; > } > > +static void > +virtio_transport_recv_enqueue(struct vsock_sock *vsk, > + struct virtio_vsock_pkt *pkt) > +{ > + struct virtio_vsock_sock *vvs = vsk->trans; > + bool free_pkt = false; > + > + pkt->len = le32_to_cpu(pkt->hdr.len); > + pkt->off = 0; > + > + spin_lock_bh(&vvs->rx_lock); > + > + virtio_transport_inc_rx_pkt(vvs, pkt); > + > + /* Try to copy small packets into the buffer of last packet queued, > + * to avoid wast...

...-841,24 +847,60 @@ virtio_transport_recv_connecting(struct sock *sk, > return err; > } > > +static void > +virtio_transport_recv_enqueue(struct vsock_sock *vsk, > + struct virtio_vsock_pkt *pkt) > +{ > + struct virtio_vsock_sock *vvs = vsk->trans; > + bool free_pkt = false; > + > + pkt->len = le32_to_cpu(pkt->hdr.len); > + pkt->off = 0; > + > + spin_lock_bh(&vvs->rx_lock); > + > + virtio_transport_inc_rx_pkt(vvs, pkt); > + > + /* Try to copy small packets into the buffer of last packet queued, > + * to avoid wast...

...REQUEST) and from that point on, receive nothing else. Now, looking at the code (under usr/kinit/ipconfig for those following at home): packet.c: packet_recv() | ? | if (udp->source != htons(cfg_remote_port) || | udp->dest != htons(cfg_local_port)) | goto free_pkt; | ? | free_pkt: | free(ip); | return 0; | ? Which means in case of source/dest mismatch (which is the case when a message from another client is received), 0 is returned. Now, looking at the callers: bootp_proto.c: bootp_recv_reply() & dhcp_proto.c: dhcp_recv() | ? |...

...atic void vhost_vsock_handle_tx_kick(struct vhost_work *work) /* Only accept correctly addressed packets */ if (le64_to_cpu(pkt->hdr.src_cid) == vsock->guest_cid) - virtio_transport_recv_pkt(pkt); + virtio_transport_recv_pkt(&vhost_transport, pkt); else virtio_transport_free_pkt(pkt); @@ -786,52 +832,6 @@ static struct miscdevice vhost_vsock_misc = { .fops = &vhost_vsock_fops, }; -static struct virtio_transport vhost_transport = { - .transport = { - .get_local_cid = vhost_transport_get_local_cid, - - .init = virtio_transport_do_s...

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v3: - Patch 1: added a threshold to copy only small packets [Jason] - Patch 1: replaced the allocation of a new buffer

...ince my TP-LINK TL-R402M router will give an icmp(ping) packet before DHCPOFFER, the ipconfig will fail after it receive the packet and tries unpack teh packet in packet_recv() since we have a packet form checking there: if (ntohs(ip->tot_len) > ret || ip->protocol != IPPROTO_UDP) goto free_pkt; ip config will fall in a loop and always got the icmp packet instead of DHCPOFFER packet in this situation. If I change the retrun value of packet_peek and make a packet form checking in more early stage, I can avoiding ipconfig fall in a loop with icmp packet, like this: --- /work/atcs/os_pkg...

...ock */ > + spin_lock_bh(&vsock_table_lock); > + if (!__vsock_in_bound_table(vsk) && !__vsock_in_connected_table(vsk)) { > + spin_unlock_bh(&vsock_table_lock); > + (void)virtio_transport_reset_no_sock(t, pkt); > + release_sock(sk); > + sock_put(sk); > + goto free_pkt; > + } > + spin_unlock_bh(&vsock_table_lock); > + As an a simpler alternative, can we check the sk_shutdown or the socket state without check again both bound and connected tables? This is a data path, so we should take it faster. I mean something like this: if (sk->sk_shutdown...

...t_recv_pkt(struct virtio_transport *t, > > lock_sock(sk); > > + /* Check if sk has been released before lock_sock */ > + if (sk->sk_shutdown == SHUTDOWN_MASK) { > + (void)virtio_transport_reset_no_sock(t, pkt); > + release_sock(sk); > + sock_put(sk); > + goto free_pkt; > + } > + > /* Update CID in case it has changed after a transport reset event */ > vsk->local_addr.svm_cid = dst.svm_cid; > > -- > 2.17.1 > Anyway, the patch LGTM, let see what David and other say. Reviewed-by: Stefano Garzarella <sgarzare at redhat.com>...

...} @@ -1040,7 +1037,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_lock_bh(&vvs->rx_lock); - can_enqueue = virtio_transport_inc_rx_pkt(vvs, skb); + can_enqueue = virtio_transport_inc_rx_pkt(vvs, len); if (!can_enqueue) { free_pkt = true; goto out; When we used vsock_pkt, we were passing the structure because the `len` field was immutable (and copied from the header), whereas with skb it can change and so we introduced these errors. What do you think? Thanks, Stefano

...ck_sock *vsk, > + struct sockaddr_vm *remote_addr, > + struct msghdr *msg, > + size_t len); > + > +void virtio_transport_destruct(struct vsock_sock *vsk); > + > +void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_inc_tx_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_dec_tx_pkt(struct virtio_vsock_pkt *pkt); > +u32 virtio_transport_get_credit(struct virtio_transport *trans, u32 wanted); > +void virtio_transport_put_credit(struct...

...ck_sock *vsk, > + struct sockaddr_vm *remote_addr, > + struct msghdr *msg, > + size_t len); > + > +void virtio_transport_destruct(struct vsock_sock *vsk); > + > +void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_inc_tx_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_dec_tx_pkt(struct virtio_vsock_pkt *pkt); > +u32 virtio_transport_get_credit(struct virtio_transport *trans, u32 wanted); > +void virtio_transport_put_credit(struct...

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v5: - rebased all patches on net-next - added Stefan's R-b and Michael's A-b v4:

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v5: - rebased all patches on net-next - added Stefan's R-b and Michael's A-b v4:

...ock_sock *vsk, > + struct sockaddr_vm *remote_addr, > + struct iovec *iov, > + size_t len); > + > +void virtio_transport_destruct(struct vsock_sock *vsk); > + > +void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_inc_tx_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_dec_tx_pkt(struct virtio_vsock_pkt *pkt); > +u64 virtio_transport_get_credit(struct virtio_transport *trans); > +#endif /* _LINUX_VIRTIO_VSOCK_H */ > diff --git...

...ock_sock *vsk, > + struct sockaddr_vm *remote_addr, > + struct iovec *iov, > + size_t len); > + > +void virtio_transport_destruct(struct vsock_sock *vsk); > + > +void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_inc_tx_pkt(struct virtio_vsock_pkt *pkt); > +void virtio_transport_dec_tx_pkt(struct virtio_vsock_pkt *pkt); > +u64 virtio_transport_get_credit(struct virtio_transport *trans); > +#endif /* _LINUX_VIRTIO_VSOCK_H */ > diff --git...

...irtio_transport_dgram_enqueue(struct vsock_sock *vsk, + struct sockaddr_vm *remote_addr, + struct msghdr *msg, + size_t len); + +void virtio_transport_destruct(struct vsock_sock *vsk); + +void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt); +void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt); +void virtio_transport_inc_tx_pkt(struct virtio_vsock_pkt *pkt); +void virtio_transport_dec_tx_pkt(struct virtio_vsock_pkt *pkt); +u32 virtio_transport_get_credit(struct virtio_transport *trans, u32 wanted); +void virtio_transport_put_credit(struct virtio_transport *t...

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v4: - rebased all patches on current master (conflicts is Patch 4) - Patch 1: added Stefan's R-b - Patch 3: removed