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=JHsZpNhk; 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 B27555A026F for ; Fri, 25 Apr 2025 10:07:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745568432; 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=gAtQA11gwBFfi8bYodXmKPJ2D5P38kuAdLUZZ/jNv+A=; b=JHsZpNhkypUwtpuu0BKtAYCzgZJY31NdC+W6t6L9JV20S4X9oEHB/ejpCFoMK/gOPksm/z ObdWSwImNpUVgbB/yPP+Ob4lL74G4eKrBV7dycpZ+bT1jPdTr8V0atWXPS2kztU5hsMiMP rBSQhONjaUogV+hpy9gUN5La2xHW2u4= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-621-JO3Z9NUqNcSbp2nn-ncFiA-1; Fri, 25 Apr 2025 04:07:10 -0400 X-MC-Unique: JO3Z9NUqNcSbp2nn-ncFiA-1 X-Mimecast-MFC-AGG-ID: JO3Z9NUqNcSbp2nn-ncFiA_1745568429 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-39d917b1455so619124f8f.3 for ; Fri, 25 Apr 2025 01:07:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745568429; x=1746173229; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gAtQA11gwBFfi8bYodXmKPJ2D5P38kuAdLUZZ/jNv+A=; b=m2JpkBifS0q6jBue8EwU7R/a6MwsKEIP5zFTI/APSNKKVWScOqJ/8xypAwv/28GMK3 tP0vbQ71J7+vg4H5r+sa81GDwtsYpJTqrm3teQwOnDty2svOJY3DGO/f1q8XZp/ceBjs /Ba1S9JYtTkTgxb9x+JH2kDV8D60VvqmGK41eF7FDaCc67k/6gWMMACOsGLdzQOO0hXS odeXFDWmpMvASPJOdCZwaQKuP9TBALUD1xVraHpT+DGjfqWTC9pB7acUA++FQwOaalwy EMbqUJmJtAZNGNP4DQtpDAhV/DNOmoVcxaa4u5v/Kvtp9X3xvmjaBLoFfyrrF9cUOUj7 MAtQ== X-Gm-Message-State: AOJu0YyKkVKqcXGKdnJVIpzYSMO31f2SXPqAyBbdZ4ZYjhUt0oprpMUY KA8vRdWliliTm8DZZTB11YRGF3tQyReWOSLUCrrEOBoRPj6GsGLpeOaIbIYZlcV9KQebkY/Lk88 D7R4X4mcNUql4dPbMEE7y8kQBgrsL+9lNT13fn8Dlg+957KfZSA== X-Gm-Gg: ASbGncuZdGrMosLTthq1tTuZ0/u25X2nHzOCQU+KNyd+DrLYAD9vX9vLTOdRRQ4kBgo Yo/stVIZRFB3y3LocCchMeZlxPkIFvyjwmAc0zDQw2EiCx7wAg8+zcl9tB+k1FmJzKz0sv5vfUg j77KegJJeHBxKTkVifTK1H2gwD+H2B5k+1cmMeF0kKyrkXqxJlyNYR5O13/mMbrn4wOVzGAtMtc NGFei6tUBrW46ATBJLWMtleSijWoAn31hyOf36cc74W12JFuKzuL9IJHu9zjQT1rLPk8gYbxGCg n+9H9+hCyovYeaekHNI4UJs= X-Received: by 2002:a05:6000:1849:b0:39a:cd84:a77a with SMTP id ffacd0b85a97d-3a074f398f1mr829234f8f.37.1745568429237; Fri, 25 Apr 2025 01:07:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEeRQROhG8X4/qRM6FFXYAbTfY3GZ3SNhSqxiufcXRr75AXnd1o8ef3d2rB/gLfVMqRbYEoUQ== X-Received: by 2002:a05:6000:1849:b0:39a:cd84:a77a with SMTP id ffacd0b85a97d-3a074f398f1mr829201f8f.37.1745568428774; Fri, 25 Apr 2025 01:07:08 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a073cbf04dsm1623971f8f.52.2025.04.25.01.07.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Apr 2025 01:07:08 -0700 (PDT) Date: Fri, 25 Apr 2025 10:07:06 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 00/12] Use connect()ed sockets for both sides of UDP flows Message-ID: <20250425100706.5726013a@elisabeth> In-Reply-To: References: <20250404101542.3729316-1-david@gibson.dropbear.id.au> <20250425082700.0bbbf2a8@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: anv1SBl3qRsJ721Fd4QoeKFtpBIf9vsK2bNahqP_9CY_1745568429 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: O3XTMV266X5FYYNJWHABGPVZAKHR3UGR X-Message-ID-Hash: O3XTMV266X5FYYNJWHABGPVZAKHR3UGR 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, Jon Maloy 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, 25 Apr 2025 13:49:26 +0700 David Gibson wrote: > On Fri, Apr 25, 2025 at 08:27:00AM +0200, Stefano Brivio wrote: > > On Fri, 4 Apr 2025 21:15:30 +1100 > > David Gibson wrote: > > > > > As discussed, I've been working on using connect()ed sockets, rather > > > than dups of the listening sockets for handling traffic on the > > > initiating side of UDP flows. This improves consistency, avoids some > > > problems (bug 103) and will allow for some useful future improvements. > > > > > > It has the nice side effect of allowing some more code to be shared > > > between various paths, resulting in a pretty nice negative diffstat. > > > > > > David Gibson (12): > > > udp: Use connect()ed sockets for initiating side > > > udp: Make udp_sock_recv() take max number of frames as a parameter > > > udp: Polish udp_vu_sock_info() and remove from vu specific code > > > udp: Don't bother to batch datagrams from "listening" socket > > > udp: Parameterize number of datagrams handled by > > > udp_*_reply_sock_data() > > > udp: Split spliced forwarding path from udp_buf_reply_sock_data() > > > udp: Merge vhost-user and "buf" listening socket paths > > > udp: Move UDP_MAX_FRAMES to udp.c > > > udp_flow: Take pif and port as explicit parameters to > > > udp_flow_from_sock() > > > udp: Rework udp_listen_sock_data() into udp_sock_fwd() > > > udp: Fold udp_splice_prepare and udp_splice_send into udp_sock_to_sock > > > udp_flow: Don't discard packets that arrive between bind() and > > > connect() > > > > Just for the record: it's likely that something here made > > https://github.com/containers/podman/issues/25959 more visible (or > > directly caused it). I couldn't rule out recent ICMP changes yet, > > but I'm fairly sure it's not those. > > Drat. I concur this series is the likely culprit. First place to > check would be the error paths for a flow initiated from the host side > (there are new ones because this now involves opening a new socket). > Maybe we didn't clean something up in one of those cases leaving a > bomb for a future allocation. Right, either that, or perhaps the flow_defer_handler() loop setting free_head to NULL if the UDP flow is (!closed) regardless of what happened in the previous loop iterations... that looks a bit weird to me. -- Stefano