On Sun, Jan 11, 2026 at 11:59:44AM +0100, Michal Luczaj wrote:
On 1/9/26 17:18, Stefano Garzarella wrote:
On Thu, Jan 08, 2026 at 10:54:54AM +0100, Michal Luczaj wrote:
...
@@ -1375,7 +1375,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
* of a new message.
*/
if (skb->len < skb_tailroom(last_skb) &&
- !(le32_to_cpu(last_hdr->flags) & VIRTIO_VSOCK_SEQ_EOM)) {
+ !(le32_to_cpu(last_hdr->flags) & VIRTIO_VSOCK_SEQ_EOM) &&
+ !skb_is_nonlinear(skb)) {
Why here? I mean we can do the check even early, something like this:
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1361,7 +1361,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
* to avoid wasting memory queueing the entire buffer with a small
* payload.
*/
- if (len <= GOOD_COPY_LEN && !skb_queue_empty(&vvs->rx_queue)) {
+ if (len <= GOOD_COPY_LEN && !skb_queue_empty(&vvs->rx_queue) &&
+ !skb_is_nonlinear(skb)) {
struct virtio_vsock_hdr *last_hdr;
struct sk_buff *last_skb;
Right, can do. I've assumed skb being non-linear is the least likely in
this context.
Yeah, but it's a very simple check, so IMHO the code is more readable if
we put it in the first conditions, where we check if the current packet
has the requisites, rather than in the nested conditions, where we check
that the packet already queued can receive the new payload.
I would also add the reason in the comment before that to make it clear.
OK, sure.
Thanks,
Stefano
