From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=bZl8dErQ; 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 D42B35A0632 for ; Thu, 13 Feb 2025 20:17:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739474227; 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=rhyKjobK8gagVCn3HONbPiN6b4iial6FCmmzlI89sTY=; b=bZl8dErQErvD1S2Qje0Jg8CmZQcnMqMQPfjkUaeI/suOB7pSSl4Dkbw5CRr/FL84m/ixvd C9PNbnKLsIQZvbS7r+3tkvBmYzWkwdnVgHoZSQcRjxwbD4wUTSuaUQDJdJJUU4dZD5nOe8 xO/H4yaC3bBxoqh1Wr3ioEfCv8WI+Z0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-144-hUUaRAIBOqWum527pQKhZQ-1; Thu, 13 Feb 2025 14:17:06 -0500 X-MC-Unique: hUUaRAIBOqWum527pQKhZQ-1 X-Mimecast-MFC-AGG-ID: hUUaRAIBOqWum527pQKhZQ_1739474225 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4394c489babso6935435e9.1 for ; Thu, 13 Feb 2025 11:17:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739474225; x=1740079025; 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=rhyKjobK8gagVCn3HONbPiN6b4iial6FCmmzlI89sTY=; b=CH0Rk0/7nN9Q0YEh7GkhsoQBqHdmwueKI/oFsfW3iJa5bfJ7ChNrtMGyKl+MPkfkcF aM0WyloYrSr5tZ2Wk3NnhRPj12XA+UTsEusZP8YxctlHc6aJ1tmyQKVVQQL8e+Vj7+qN XCTUdnVwRFJKMc1H4gtB+mrRvIHL/MhCaiKIJztnUffkm4ysPeVgqwiDgDtxJrQamxTN A/zm0SotX4SXb+BcN0VLOGKyJIZGd89MXm/QHoc+NWExTgOzP55Q8crumC5+c77qq35I bAvQPfjDIEuPfOR7SrS+EGB45nTlIKJintq1jbgkYKYf4ydNg6Ku12Wc8XUo5sWszwdO piiw== X-Forwarded-Encrypted: i=1; AJvYcCVS6zWCAo905KZ3R2ok+uU8PiMQBKG3/C2YQm7JU/eHLW+0XHq62iEtnp1e/3x9UH9E7rwlouzytmo=@passt.top X-Gm-Message-State: AOJu0Yw++69HMYjymQ2NBHUbPU7VeOa1/RZQAPAOiF0vbMC9ON5drQ08 nLrTi0ciIOaUoJZXD+CRIcGinO/FKRMro2FNc/toctqw3hsyegO1Jxp2mlpg3cfL5wKVHrUNBtG CzN0+s5pkA8sZ1Ke/BRK6VZ6IqrQ7JHvxKruPgGdcBc7Ezpi4ew== X-Gm-Gg: ASbGnctipzlNL33sJ1M6RhRMORgO8infdceYNdyCnJB9lQqRazqu1oxfa8heqTQrj65 VoFxN9yA+ksGHOMv9GxlxhR+AwyseGl2TVnLj0Rrf4DWpqkLe6dw/ujBp14cnr/NSkENgGWsXYW MkAYlBb3R6tf1je6EeHCwWPxzOa9HkTR38vo5LrvFVrzpUKI3Ic4Ew9/KAc0TWp4Ihhr6VRguWP MTOhQLrKpDJH1bSec8dfxlu7Zy68i0UcpN1lFtGPa3SiUs+uKiB067G5mScIWWTEnpoSDnKdaqA 9Fww37X66+YZwbhR X-Received: by 2002:a05:600c:c17:b0:434:9e46:5bc with SMTP id 5b1f17b1804b1-43960179b9dmr66099445e9.10.1739474225023; Thu, 13 Feb 2025 11:17:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IHfJ2O9tvRwEA0QYcfOdMITXNJXCT7NKjWEPRk/EAMpRoKid5E6IulvsglP2FciGDv4y+bIOg== X-Received: by 2002:a05:600c:c17:b0:434:9e46:5bc with SMTP id 5b1f17b1804b1-43960179b9dmr66099035e9.10.1739474224592; Thu, 13 Feb 2025 11:17:04 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4395a06d237sm56415755e9.21.2025.02.13.11.17.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2025 11:17:04 -0800 (PST) Date: Thu, 13 Feb 2025 20:17:02 +0100 From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH] udp: create and send ICMPv4 to local peer when applicable Message-ID: <20250213201702.461b034f@elisabeth> In-Reply-To: References: <20250209170056.1160547-1-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -L8eefyAbpg52HuCaiKHkDWCJhWXPPl6_Y-8xeWnX7g_1739474225 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2WHEEE4D5YK3HJHXFLVT6VWU2GDAP3AT X-Message-ID-Hash: 2WHEEE4D5YK3HJHXFLVT6VWU2GDAP3AT 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: David Gibson , passt-dev@passt.top, lvivier@redhat.com, dgibson@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 Thu, 13 Feb 2025 14:07:22 -0500 Jon Maloy wrote: > On 2025-02-12 16:39, Jon Maloy wrote: > > On 2025-02-10 19:55, David Gibson wrote: =20 > >> On Sun, Feb 09, 2025 at 12:00:56PM -0500, Jon Maloy wrote: =20 > >>> +=C2=A0=C2=A0=C2=A0 const struct flowside *toside =3D flowside_at_sid= x(tosidx); > >>> +=C2=A0=C2=A0=C2=A0 struct in_addr oaddr =3D toside->oaddr.v4mapped.a= 4; > >>> +=C2=A0=C2=A0=C2=A0 struct in_addr eaddr =3D toside->eaddr.v4mapped.a= 4; > >>> +=C2=A0=C2=A0=C2=A0 struct iov_tail data =3D IOV_TAIL(iov, 1, 0); > >>> +=C2=A0=C2=A0=C2=A0 struct { > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct icmphdr icmp4h; > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct iphdr ip4h; > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct udphdr uh; > >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char data[8]; > >>> +=C2=A0=C2=A0=C2=A0 } msg; =20 > >> > >> Needs a ((packed)) attribute to ensure we don't get compiler padding. = =20 >=20 > I get > udp.c:437:23: warning: taking address of packed member of =E2=80=98struct= =20 > =E2=80=99 may result in an unaligned pointer value=20 > [-Waddress-of-packed-member] > 437 | tap_push_ip4h(&msg.ip4h, eaddr, oaddr, udplen,=20 > IPPROTO_UDP); >=20 > Also, the sizes of these members are 8+20+8+8, so I cannot see how > this struct can possibly be packed or how there can be an unaligned > pointer. Unaligned pointer because it's on the stack, and it can happily be at a semi-random point of it. Packed needs to be packed because you could have 8 + 20 + ("oops we are at 28 let's make it 32") 4 + 8 + 8. > In short: ((packed)) seems unnecessary, and only causes problems. ...well, but it still should be ((packed)) because it goes on the wire, and ((aligned)) because you need to access the single fields: __attribute__((packed, aligned(__alignof__(max_align_t)))); meaning: align it to whatever any kind of machine might possibly need. --=20 Stefano