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=ga04VVfd; 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 B167B5A026E for ; Fri, 03 Apr 2026 18:59:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775235594; 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; bh=zHdmuTDri1yV9b2iX55dFpJyNHRHem3p9twGq4A8iuo=; b=ga04VVfdzI7siKRLe87dlJm+DppZ4xHBPEdKD2vXlu2RPdPRk3gsS028qW1nXdw3UT1nlg TlcIEA9Cic/kD7bqSaX4cYDF/pNa9UQ6fc/mHFItdNGE1M0ZfjrT3BIkuNnXX/dMYhoH0m 9FoZ6w0L867igHTcSVmvwnyDLTWWbMc= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-553-uvoVW6UOMvi-_h7AgqvCzQ-1; Fri, 03 Apr 2026 12:59:53 -0400 X-MC-Unique: uvoVW6UOMvi-_h7AgqvCzQ-1 X-Mimecast-MFC-AGG-ID: uvoVW6UOMvi-_h7AgqvCzQ_1775235592 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4836abfc742so19492365e9.0 for ; Fri, 03 Apr 2026 09:59:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775235591; x=1775840391; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zHdmuTDri1yV9b2iX55dFpJyNHRHem3p9twGq4A8iuo=; b=JRSTL50ooTCbR+fjOz8rWGAMFOB1GNex8gn0FF2a5dqt+YnyAX7GStbfzJtKA/sktG ue1TrNUZaxU624/kna2biOJI8Mm208lgTpuT0Jpx/vdwRaVDCKY2qNSd8b9ly99B0OeH XtLE1f5v1aq6yNE6EJP30ujrMcM9uF/3JMUMqj1wLPuwvCFHn5rCJ0yRaP2Q/IixD4O2 wrOnm4GcME4YnrCkUl18xsKJ5X0mEOC44RFvLMDeMVjEc4eXroMNKzr5YhDcjylKWVKl eKIiPbTwCBm+y8uVPf/6KuDizYWWwpfNHAzosejDZXmD4ED94C4MDPuqeSF6HbBn4oIO ztZw== X-Gm-Message-State: AOJu0YzIX3efc1vD1TZbpfGM+8Q7eZuZSlTXY/fVc0DivbMz4Ayh/rzC u3UFWLW8KP9tSEb1dqvzOyauqnn7sh4BnK4f7dA7q6Z3N5sidylns35LnR1mXTUCdhHcpczGKgT N8u5SahF7I4VQc6fSgGEq29bGa+sInU+vu5WktnSvIKKphTQkNuTPqcJPAjugWdt6kF3tsWUZUx NFHM/zY92VGlduZe2eUqRA1xEw8M6TuDvtpHG1 X-Gm-Gg: ATEYQzyUj+4uOVdK/VqfE1qHePH31Ld1emyLD+h6pQYPsjewVnkTE4wveLKq/1JOE4l y6pyBjLslNGJ85ajw1pJ5/0rzV+LDR6zvvrftRbUMW1WrdplImJwuqStXiOly4Vax+/e/0qehxu M298kit/BTYwBqMsy/xgX1mGDjgQIpZAJSbKCSufEvatPeb2Jde+dGjqxXHjFU+gFc4xBwZfvg+ wNkoK0L1ZdIce6PwGOp3IgvfcSHCyaPFQ5G8CTjCQCk2H7L6QKT00cE+ikOksF5REA+M76w70jR 2zPz8TEGJtk86jTDOhPHGMBWJXHFCzNo/1Y+uHFi67ywIDRgECZ8CLTNubd3cTm7rCqtdZ4JQWr hRdZVMpohKZZp1LPPlK7xKn+cTNnnHxzIU2gWefjXwph0IxS6Ow== X-Received: by 2002:a05:600c:3546:b0:485:9a50:3370 with SMTP id 5b1f17b1804b1-488996e1d39mr53024145e9.8.1775235591295; Fri, 03 Apr 2026 09:59:51 -0700 (PDT) X-Received: by 2002:a05:600c:3546:b0:485:9a50:3370 with SMTP id 5b1f17b1804b1-488996e1d39mr53023675e9.8.1775235590514; Fri, 03 Apr 2026 09:59:50 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e832585sm524205275e9.6.2026.04.03.09.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2026 09:59:49 -0700 (PDT) From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v6 1/3] udp_vu: Allow virtqueue elements with multiple iovec entries Message-ID: <20260403185948.4f9f9bbc@elisabeth> In-Reply-To: <032ffd0c-1f46-435b-adeb-7cceea4d30b7@redhat.com> References: <20260401192326.1783350-1-lvivier@redhat.com> <20260401192326.1783350-2-lvivier@redhat.com> <20260403135309.1d84f5dd@elisabeth> <032ffd0c-1f46-435b-adeb-7cceea4d30b7@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Fri, 03 Apr 2026 18:59:49 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: k8mBPRMj3S5LkGliXnaxJRdBoYYfUeKEwg_YcKI-8U0_1775235592 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TL5PVOEEVUMGA3ALQJAFBREOB2EO6V2J X-Message-ID-Hash: TL5PVOEEVUMGA3ALQJAFBREOB2EO6V2J X-MailFrom: sbrivio@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 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... -- Stefano