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=CCG1KoS1; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 7F40A5A026E for ; Fri, 03 Apr 2026 19:14:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775236454; 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=TCZVBWaogI48paEoY6W1YwhGAFOgQa8zS01o3X4WArk=; b=CCG1KoS16p6hO126+d81yTBFmBXAdZW8yRO4Dl5Y6y339osm/X+tAtXNRDF0j1200sT4R1 2YME85jvGbnBvQI+N3GbVejjMy6FRrD/aSq9/HCi2n8I+RYD/PTA6Iff8Ec/I5fD3zf6UH V3u6jbTNzejrKjZGeNATrVHUvnIT1sE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-344-tYHlK3OZNiqLNHTMq086Aw-1; Fri, 03 Apr 2026 13:14:13 -0400 X-MC-Unique: tYHlK3OZNiqLNHTMq086Aw-1 X-Mimecast-MFC-AGG-ID: tYHlK3OZNiqLNHTMq086Aw_1775236452 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4887e4b338bso36008965e9.1 for ; Fri, 03 Apr 2026 10:14:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775236452; x=1775841252; 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=TCZVBWaogI48paEoY6W1YwhGAFOgQa8zS01o3X4WArk=; b=Mx73UCxcbCOP2fFKNVxZy++HQiRvKQVF1GLaKhX2h1m4cvBPOXSS8GFzeCNnghnGFw 0Jh65VrXDxNBkPBG7z8Bbt2969Jr5RPwZoYQuRLnh61OGGZeiHNvJVvNUiB7f4UQ1/rf xPHEWBC25EkJagjFm6Jj4LDye+xc3zU4RpxIWqkzzOUKIRmaj9m2oMx/lQfn2Ty4LgHd rrFWBOPhghxp3yCWuX+pYUfFMlQvQ6G9jCNT9B/fK+oeAsOcXixIJF4M5NgRwkZ1tL57 MWbX6shVSoPU0OT0cf0gzFTxCnOgbvInyhL5SmYrZaZFBsnxrPvdyFFuXNn5pChyPtJC mJzQ== X-Gm-Message-State: AOJu0YxxG2gRQ+CWLbJojReyCTPmnn0+9htpOLdG+qlWbf81zF8+MBNy K5ezr1P92T+hcSg4Yzz2T7MJZYguNLqFYsbnNwYKh+GMhhOu14txivslllghrbN5L/9e+7Tr/IJ 2vFXKU+mmE61+rFbICo367N+QhDl0sbjEZ0NZoAoBcg5fBd5UmKuQJA== X-Gm-Gg: ATEYQzwJR7UcVACPOI19U3cp5MEodpV1qHh6recci9UIQiUQ4Ig6gfm9VXCvQBG31Tk ijq0Kd2vmILlbCH9mOBmmgoVmrSdOC2b5WiTUXa8+ZcFmOmlqhPahwpRqA2vk0TgicsJp3Qih+Q Bv6PNb8jrvUuEXw48r8nqyNAGuSLDa3/Nzsa7a8r8G6h3Tb6rNki4KmbVOqWVnt5EZguq/dxc50 S2QSirvy7tYE6D1PLAOvg+mo7QkqFToh0RvDAaowdzuOR7TuT8sHLdCcON4kFgOgB9yoVWjtMNR 92n7P9zaUAvDjRf4CUo4jJ59KKf3xv/nq1lfKnXsjrzHAcVS8VdYwM13vrYzr1mRHqD0phqy6d6 06tKoTHE9GjRFWuGzucNmVW8iT7DtIVxb1FpDa6Wrb5GzPIU8HYlTcDs= X-Received: by 2002:a05:600c:4e42:b0:486:f893:56c6 with SMTP id 5b1f17b1804b1-4889949c0f1mr58057625e9.10.1775236451853; Fri, 03 Apr 2026 10:14:11 -0700 (PDT) X-Received: by 2002:a05:600c:4e42:b0:486:f893:56c6 with SMTP id 5b1f17b1804b1-4889949c0f1mr58057145e9.10.1775236451217; Fri, 03 Apr 2026 10:14:11 -0700 (PDT) Received: from [192.168.100.100] (82-64-211-94.subs.proxad.net. [82.64.211.94]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48899e420efsm34216385e9.9.2026.04.03.10.14.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2026 10:14:10 -0700 (PDT) Message-ID: <9ee8be6c-b5ae-4939-9225-bdffff80f216@redhat.com> Date: Fri, 3 Apr 2026 19:14:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/3] udp_vu: Allow virtqueue elements with multiple iovec entries To: Stefano Brivio References: <20260401192326.1783350-1-lvivier@redhat.com> <20260401192326.1783350-2-lvivier@redhat.com> <20260403135309.1d84f5dd@elisabeth> <032ffd0c-1f46-435b-adeb-7cceea4d30b7@redhat.com> <20260403185948.4f9f9bbc@elisabeth> 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: <20260403185948.4f9f9bbc@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: k6msNmivgR4LQRfe0VxIrZFuBRa1BNWy6K7c0TkAcyA_1775236452 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: OWUVOZ6PBXTDRDKCKGL3F7JQ4EXJP7E3 X-Message-ID-Hash: OWUVOZ6PBXTDRDKCKGL3F7JQ4EXJP7E3 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: passt-dev@passt.top 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 4/3/26 18:59, Stefano Brivio wrote: > On Fri, 3 Apr 2026 17:18:23 +0200 > Laurent Vivier wrote: > >> On 4/3/26 13:53, Stefano Brivio wrote: >>> On Wed, 1 Apr 2026 21:23:24 +0200 >>> Laurent Vivier wrote: >>> >>>> The previous code assumed a 1:1 mapping between virtqueue elements and >>>> iovec entries (enforced by an assert). Drop that assumption to allow >>>> elements that span multiple iovecs: track elem_used separately by >>>> walking the element list against the iov count returned after padding. >>>> This also fixes vu_queue_rewind() and vu_flush() to use the element >>>> count rather than the iov count. >>>> >>>> Use iov_tail_clone() in udp_vu_sock_recv() to handle header offset, >>>> replacing the manual base/len adjustment and restore pattern. >>>> >>>> Signed-off-by: Laurent Vivier >>>> --- >>>> udp_vu.c | 29 ++++++++++++++--------------- >>>> 1 file changed, 14 insertions(+), 15 deletions(-) >>>> >>>> diff --git a/udp_vu.c b/udp_vu.c >>>> index 30af64034516..5608a3a96ff5 100644 >>>> --- a/udp_vu.c >>>> +++ b/udp_vu.c >>>> @@ -64,30 +64,25 @@ static size_t udp_vu_hdrlen(bool v6) >>>> */ >>>> static ssize_t udp_vu_sock_recv(struct iovec *iov, size_t *cnt, int s, bool v6) >>>> { >>>> + struct iovec msg_iov[*cnt]; >>> >>> Variable-length Arrays (VLAs) are allowed starting from C99 but we >>> should really really avoid them. If 'cnt' is big enough, we risk >>> writing all over the place. That's the main reason why they were more >>> or less banned from the Linux kernel some years ago and eventually >>> eradicated: >> >> I can use alloca() if you prefer ;) > > Claude, is this you? ;) > > I guess if you come up with a sufficient convoluted maze of "elem" / > "iov" / "head" macros using concatenation to strategically place calls > to strndupa(), with an abstraction based on IOV "tails" called "strain" > indicated by "strn" for brevity... one day I might miss that, yes. > > But I'll try to remember that, the next time we discuss whether it's > really needed to duplicate strain A or if a single copy of it is enough. > >>> https://lore.kernel.org/lkml/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com/ >>> >>> https://lore.kernel.org/lkml/20181028172401.GA41102@beast/ >>> >>> Can we use VIRTQUEUE_MAX_SIZE as upper bound like udp_vu_sock_to_tap() >>> does? >> >> Yes, but the idea here is we have always *cnt < VIRTQUEUE_MAX_SIZE >> (because the value comes from vu_collect() and in vu_collect(): >> *in_sg (&iov_cnt or *cnt) < max_in_sg (ARRAY_SIZE(iov_vu) or VIRTQUEUE_MAX_SIZE or 1024) > > ...until somebody, running this somewhere where we don't have gcc's > stack protector stuff (or equivalent), without having quite obtained > full arbitrary code execution yet, finds a way to manipulate *cnt... > >> And vu_collect(), in this case, sets generally *in_sg to a value lower than 44: >> we want to create a frame of ETH_MAX_MTU by coalescing kernel buffers of size ETH_FRAME_LEN) > > If it _can_ be 16 KiB, then I would suggest it's better to _just_ have > 16 KiB. It's more auditable, and it's not like we "allocate" it anyway. > > On top of it, udp_vu_sock_to_tap() already does that, and other > functions (with potentially deeper call trees) do worse. I'm not > claiming it's a good idea to do it "because it's bad anyway", in > general, but in this case the maximum is what matters. > >> For me 16 kB on the stack is a lot of memory (but I started programming on a 48 kB RAM >> computer...). > > I guess I started with around ten times that but I tend to agree. What > I'm suggesting is that if it can be a lot, better just make it that lot. > > An alternative I'm pondering about is whether we can make things > recoverably / gracefully fail if that's > 64 or something like that. At > this point we still have that data on the socket and we could dequeue > it in a later pass I suppose. But maybe it gets very complicated... > I understand. I already sent a v6 without this change but for the v7 I will remove the VLA (without using alloca()). Thanks, Laurent