From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JIM7nx6G; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 9DA1E5A026D for ; Mon, 15 Jun 2026 10:47:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781513272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=eopqEr3Tgwe8q32P2odrbDDbi+82R0HdpQenFKqb8Rw=; b=JIM7nx6GEUN8IMEeMKNPUuOPUWN4KETgrh2Axf9z9FBv4BkzX1waVoFAZ0MlYS4SIAnFuy ynDETP05aGIEIicNkDLrCzfD4jAOQOSWQVEibJ09oQBQfq2tMZgMEnfYNXOndtKuHzBkmJ 9XJQg7zMMU/+RGox+3Sx/3qzlMCSKDU= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-505-lAOpjOAVNwCjTWVyNGhrAw-1; Mon, 15 Jun 2026 04:47:50 -0400 X-MC-Unique: lAOpjOAVNwCjTWVyNGhrAw-1 X-Mimecast-MFC-AGG-ID: lAOpjOAVNwCjTWVyNGhrAw_1781513270 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-4601daf4c65so1830284f8f.2 for ; Mon, 15 Jun 2026 01:47:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781513269; x=1782118069; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eopqEr3Tgwe8q32P2odrbDDbi+82R0HdpQenFKqb8Rw=; b=Zti/ncbJ+gk8KIraStJL4UI14cOxAXnajo2PV7A/xHb5er+GzKpQ073VAC2wXdV9Gu BPfOLX5dq5vbKtbgWEjr7CDr0TlHrTXdU2GOVB9oIvSM5e9URa0Kzp7RoAqtjPapNgWO ITC+u/i/UeUP1eVhHqaS72O/PZ6Nmvpt17dHgv6XKKSKY39l0wIF8mnL68wiWKyY3f3J C0IPfnimcN8+f0OotiFCMvVd65aqCnrtX5CNFLTKUFKxztcn4lFPKH1wuLoLlLzdxNt4 VQIS281bqkpLOI9/uQsGV25QHtYrpGWgz5tsxuuLb1LuzC1YOHubVw7GdHdHl9Q8KNKP TVLg== X-Forwarded-Encrypted: i=1; AFNElJ+9edzr7zRIuK7o/RLoK/QrBdlOxSzQCZRoKRQnG4K0B5V3B9VtzzrntCOx1UXdgymGV4eH/09oWGg=@passt.top X-Gm-Message-State: AOJu0Ywf+JLkX43gPyClzhb+culGSDbvJkNORKaMK8V91JeOicuFf9b6 EUr2psO113lue7SXan4+Bkbzjp45pxAfbsoSr6NGb/IO7KHuMyYMy+xZvnwCwt64RE3VKOJrfiM sghAOxT7IF80EceJvgrNbQ98WPzYPL17Dt9HkcvXAhmUCvk8xNFeHzQ== X-Gm-Gg: Acq92OFft9H8YTe0L2LZDJySNgUyk4Y7+caTEwM0ofIjN1qF2xKRHojhzbNMl51W3FS RNcvm8VkV+H58gsyPcAHbLI6MK0o+P0FIsWEi0Wfy3ya7e8EKqMyMZO0ctbXAcj7MT7Tqt8pq5F W/t3xHeat4nVSBfgHeRgUJxu0ic4JdhlQmTiQEdpEIZ1iC6YwKI34gfbavrebrlRDNzbI35jqfV Y77w/bcUhPQG52KLtoR8fOcmjUdVYvJPA34vVjd8SljiwgHgNQGrCwse7blSyxdNEm4H4XKJTnE sIdlrkYEg6Q1AEHJCg0/Oic1YvPSmU2Ql+5Xe3a++VegKMajXVfUO2++fQDBOw9+s0Rh9HhQ62W mQZ/iDk5ifmK6yjzEv4K8L70OVRxo90pS0bPWSk5YXAy3Pyr8++Erk+nDvfhi X-Received: by 2002:a05:6000:26c5:b0:460:e00:121d with SMTP id ffacd0b85a97d-4606da6237bmr19462335f8f.14.1781513269310; Mon, 15 Jun 2026 01:47:49 -0700 (PDT) X-Received: by 2002:a05:6000:26c5:b0:460:e00:121d with SMTP id ffacd0b85a97d-4606da6237bmr19462267f8f.14.1781513268605; Mon, 15 Jun 2026 01:47:48 -0700 (PDT) Received: from ?IPV6:2a01:e0a:e10:ef90:343a:68f:2e91:95c? ([2a01:e0a:e10:ef90:343a:68f:2e91:95c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f2c5266sm37134220f8f.29.2026.06.15.01.47.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2026 01:47:48 -0700 (PDT) Message-ID: <2192831c-fd2b-4825-ab65-5483484ff1b8@redhat.com> Date: Mon, 15 Jun 2026 10:47:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tap: Trim Ethernet padding from short IPv4 frames instead of dropping them To: David du Colombier <0intro@gmail.com>, passt-dev@passt.top References: <20260612215804.710266-1-0intro@gmail.com> From: Laurent Vivier Autocrypt: addr=lvivier@redhat.com; keydata= xsFNBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABzSNMYXVyZW50IFZp dmllciA8bHZpdmllckByZWRoYXQuY29tPsLBeAQTAQIAIgUCVgVQgAIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQ8ww4vT8vvjwpgg//fSGy0Rs/t8cPFuzoY1cex4limJQfReLr SJXCANg9NOWy/bFK5wunj+h/RCFxIFhZcyXveurkBwYikDPUrBoBRoOJY/BHK0iZo7/WQkur 6H5losVZtrotmKOGnP/lJYZ3H6OWvXzdz8LL5hb3TvGOP68K8Bn8UsIaZJoeiKhaNR0sOJyI YYbgFQPWMHfVwHD/U+/gqRhD7apVysxv5by/pKDln1I5v0cRRH6hd8M8oXgKhF2+rAOL7gvh jEHSSWKUlMjC7YwwjSZmUkL+TQyE18e2XBk85X8Da3FznrLiHZFHQ/NzETYxRjnOzD7/kOVy gKD/o7asyWQVU65mh/ECrtjfhtCBSYmIIVkopoLaVJ/kEbVJQegT2P6NgERC/31kmTF69vn8 uQyW11Hk8tyubicByL3/XVBrq4jZdJW3cePNJbTNaT0d/bjMg5zCWHbMErUib2Nellnbg6bc 2HLDe0NLVPuRZhHUHM9hO/JNnHfvgiRQDh6loNOUnm9Iw2YiVgZNnT4soUehMZ7au8PwSl4I KYE4ulJ8RRiydN7fES3IZWmOPlyskp1QMQBD/w16o+lEtY6HSFEzsK3o0vuBRBVp2WKnssVH qeeV01ZHw0bvWKjxVNOksP98eJfWLfV9l9e7s6TaAeySKRRubtJ+21PRuYAxKsaueBfUE7ZT 7zfOwU0EVgUmGQEQALxSQRbl/QOnmssVDxWhHM5TGxl7oLNJms2zmBpcmlrIsn8nNz0rRyxT 460k2niaTwowSRK8KWVDeAW6ZAaWiYjLlTunoKwvF8vP3JyWpBz0diTxL5o+xpvy/Q6YU3BN efdq8Vy3rFsxgW7mMSrI/CxJ667y8ot5DVugeS2NyHfmZlPGE0Nsy7hlebS4liisXOrN3jFz asKyUws3VXek4V65lHwB23BVzsnFMn/bw/rPliqXGcwl8CoJu8dSyrCcd1Ibs0/Inq9S9+t0 VmWiQWfQkz4rvEeTQkp/VfgZ6z98JRW7S6l6eophoWs0/ZyRfOm+QVSqRfFZdxdP2PlGeIFM C3fXJgygXJkFPyWkVElr76JTbtSHsGWbt6xUlYHKXWo+xf9WgtLeby3cfSkEchACrxDrQpj+ Jt/JFP+q997dybkyZ5IoHWuPkn7uZGBrKIHmBunTco1+cKSuRiSCYpBIXZMHCzPgVDjk4viP brV9NwRkmaOxVvye0vctJeWvJ6KA7NoAURplIGCqkCRwg0MmLrfoZnK/gRqVJ/f6adhU1oo6 z4p2/z3PemA0C0ANatgHgBb90cd16AUxpdEQmOCmdNnNJF/3Zt3inzF+NFzHoM5Vwq6rc1JP jfC3oqRLJzqAEHBDjQFlqNR3IFCIAo4SYQRBdAHBCzkM4rWyRhuVABEBAAHCwV8EGAECAAkF AlYFJhkCGwwACgkQ8ww4vT8vvjwg9w//VQrcnVg3TsjEybxDEUBm8dBmnKqcnTBFmxN5FFtI WlEuY8+YMiWRykd8Ln9RJ/98/ghABHz9TN8TRo2b6WimV64FmlVn17Ri6FgFU3xNt9TTEChq AcNg88eYryKsYpFwegGpwUlaUaaGh1m9OrTzcQy+klVfZWaVJ9Nw0keoGRGb8j4XjVpL8+2x OhXKrM1fzzb8JtAuSbuzZSQPDwQEI5CKKxp7zf76J21YeRrEW4WDznPyVcDTa+tz++q2S/Bp P4W98bXCBIuQgs2m+OflERv5c3Ojldp04/S4NEjXEYRWdiCxN7ca5iPml5gLtuvhJMSy36gl U6IW9kn30IWuSoBpTkgV7rLUEhh9Ms82VWW/h2TxL8enfx40PrfbDtWwqRID3WY8jLrjKfTd R3LW8BnUDNkG+c4FzvvGUs8AvuqxxyHbXAfDx9o/jXfPHVRmJVhSmd+hC3mcQ+4iX5bBPBPM oDqSoLt5w9GoQQ6gDVP2ZjTWqwSRMLzNr37rJjZ1pt0DCMMTbiYIUcrhX8eveCJtY7NGWNyx FCRkhxRuGcpwPmRVDwOl39MB3iTsRighiMnijkbLXiKoJ5CDVvX5yicNqYJPKh5MFXN1bvsB kmYiStMRbrD0HoY1kx5/VozBtc70OU0EB8Wrv9hZD+Ofp0T3KOr1RUHvCZoLURfFhSQ= In-Reply-To: <20260612215804.710266-1-0intro@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: SzKfD3vfPlUiKlYydEkoMxi-4UAXDQrQk0bcXiZAiUk_1781513270 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: YTSX7MKMEMZFJQ42CDEDU3A6G2KRRXFK X-Message-ID-Hash: YTSX7MKMEMZFJQ42CDEDU3A6G2KRRXFK X-MailFrom: lvivier@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: sbrivio@redhat.com X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 6/12/26 23:58, David du Colombier wrote: > tap4_handler() requires the L2 payload after the IP header to match > the IP datagram length exactly. Guests whose drivers pad transmitted > frames to the 60 byte Ethernet minimum, as real hardware requires and > as drivers modelled on hardware do (Plan 9's virtio-net, for one), > send pure ACK and FIN segments as 60 byte frames: 14 byte Ethernet > header, 40 byte IPv4 datagram, 6 padding octets. Those frames fail > the exact length check and are dropped without trace. > > passt then never sees such a guest's acknowledgements: it > retransmits from the lowest unacknowledged sequence with exponential > backoff while the guest, which received and acknowledged everything, > waits. Every fresh connection stalls for minutes (a 1 MiB HTTP fetch > over --map-host-loopback measured 248 s before this change, 0.27 s > after; bulk transfer over established connections, whose ACKs ride > data segments above the padding threshold, is unaffected). FIN > segments are padded too, so teardown hangs as well. Note that > tap_send_single() pads passt's own outbound frames to ETH_ZLEN, so > the receive path was already stricter than the send path. > > Trim the trailing padding to the IP datagram length instead, using a > new iov_tail_trim() helper, and keep dropping frames genuinely > shorter than the datagram they claim to carry. IPv6 is unaffected: > its minimal TCP frame is 74 bytes, above the padding threshold. > > Signed-off-by: David du Colombier <0intro@gmail.com> > --- > iov.c | 35 +++++++++++++++++++++++++++++++++++ > iov.h | 2 ++ > tap.c | 11 ++++++++++- > 3 files changed, 47 insertions(+), 1 deletion(-) > > diff --git a/iov.c b/iov.c > index 6fd684a..968a365 100644 > --- a/iov.c > +++ b/iov.c > @@ -450,3 +450,38 @@ ssize_t iov_tail_clone(struct iovec *dst_iov, size_t dst_iov_cnt, > > return j; > } > + > +/** > + * iov_tail_trim() - Limit a tail to @len bytes via a scratch iovec array > + * @tail: Pointer to the iov_tail to trim; rebuilt on success to > + * reference @scratch > + * @len: Number of bytes to keep > + * @scratch: Scratch iovec array backing the trimmed tail; must stay > + * valid as long as the trimmed tail is in use > + * @scratch_cnt: Number of elements in @scratch > + * > + * Return: true on success, false if @tail is shorter than @len or does > + * not fit in @scratch (@tail is unchanged on failure) > + */ > +bool iov_tail_trim(struct iov_tail *tail, size_t len, > + struct iovec *scratch, size_t scratch_cnt) > +{ > + ssize_t cnt = iov_tail_clone(scratch, scratch_cnt, tail); > + size_t left = len; > + unsigned int i; > + > + if (cnt < 0) > + return false; > + > + for (i = 0; i < (size_t)cnt && left; i++) { > + if (scratch[i].iov_len > left) > + scratch[i].iov_len = left; > + left -= scratch[i].iov_len; > + } > + > + if (left) > + return false; > + > + *tail = IOV_TAIL(scratch, i, 0); > + return true; > +} > diff --git a/iov.h b/iov.h > index 4fdf14a..3af467e 100644 > --- a/iov.h > +++ b/iov.h > @@ -97,6 +97,8 @@ size_t iov_push_header_(struct iov_tail *tail, const void *v, size_t len); > void *iov_remove_header_(struct iov_tail *tail, void *v, size_t len, size_t align); > ssize_t iov_tail_clone(struct iovec *dst_iov, size_t dst_iov_cnt, > struct iov_tail *tail); > +bool iov_tail_trim(struct iov_tail *tail, size_t len, > + struct iovec *scratch, size_t scratch_cnt); > > /** > * IOV_PEEK_HEADER() - Get typed pointer to a header from an IOV tail > diff --git a/tap.c b/tap.c > index 4cba4c7..b929b21 100644 > --- a/tap.c > +++ b/tap.c > @@ -716,6 +716,7 @@ static int tap4_handler(struct ctx *c, const struct pool *in, > i = 0; > resume: > for (seq_count = 0, seq = NULL; i < in->count; i++) { > + struct iovec trim_iov[UIO_MAXIOV]; > size_t l3len, hlen, l4len; > struct ethhdr eh_storage; > struct iphdr iph_storage; > @@ -775,7 +776,15 @@ resume: > > if (!iov_drop_header(&data, hlen)) > continue; > - if (iov_tail_size(&data) != l4len) > + if (iov_tail_size(&data) < l4len) > + continue; > + > + /* Drivers modelled on real hardware (Plan 9's virtio, for > + * one) pad short frames to the 60 byte Ethernet minimum: > + * trim trailing padding instead of dropping the packet. > + */ > + if (iov_tail_size(&data) > l4len && Perhaps we can avoid to compute twice iov_tail_size(&data) and store it in a variable? > + !iov_tail_trim(&data, l4len, trim_iov, UIO_MAXIOV)) I think ARRAY_SIZE(trim_iov) would be a better choice than UIO_MAXIOV. > continue; > > if (iph->protocol == IPPROTO_ICMP) { otherwise LGTM. Thanks, Laurent