From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202412 header.b=pRvuO1Fn; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 893585A061F for ; Thu, 30 Jan 2025 08:44:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202412; t=1738223028; bh=JpabxXEb1Hr9H35lTuMgKHe0qIabYwElVEI+KKpt3f4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pRvuO1FnFWIDhqIjZ82Gd9KXPw0h2RP0fcNbRYBn0IPn6ynAUhHobbC4EZITef/6d 1h1UTSlirwK1O4yjsFNXtr5xiNyDXd/2lF/WvYJR1QYNCaMYCW0BjekaamxO/B/+CY 8t3gkQgx/z+1OyFdXW+WuRXDVeOu4m8rP2ffAbabwrzgV4ZYv8zsvDFiYGxlkQoDir 3LmzAqcF/D2qrmmPY1fT8Uvw6ehQ0iTzXIyOlvsxfsuyPYOx+PnB7ko6jWbWx4gLRY jduSMUJ+BtnFcRVcF0G2Y5hr6ukSotqHjEZkGf+yftAoBxP3TI/dluVlYNGtAdnVG4 RKVvo1Tfbfheg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Yk9xw21vSz4x5l; Thu, 30 Jan 2025 18:43:48 +1100 (AEDT) Date: Thu, 30 Jan 2025 18:27:10 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 3/7] tcp_conn: Avoid 7-bit hole in struct tcp_splice_conn Message-ID: References: <20250127231532.672363-1-sbrivio@redhat.com> <20250127231532.672363-4-sbrivio@redhat.com> <20250128074833.716e4a66@elisabeth> <20250129083340.38926745@elisabeth> <20250130055500.0d14a3d5@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LrhfTmPmiOrbS1qG" Content-Disposition: inline In-Reply-To: <20250130055500.0d14a3d5@elisabeth> Message-ID-Hash: HG6NBQFK6VULV5QLIC5VF5MSZ7ZXCVH4 X-Message-ID-Hash: HG6NBQFK6VULV5QLIC5VF5MSZ7ZXCVH4 X-MailFrom: dgibson@gandalf.ozlabs.org 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, Laurent Vivier 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: --LrhfTmPmiOrbS1qG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 30, 2025 at 05:55:00AM +0100, Stefano Brivio wrote: > On Thu, 30 Jan 2025 11:44:19 +1100 > David Gibson wrote: >=20 > > On Wed, Jan 29, 2025 at 08:33:40AM +0100, Stefano Brivio wrote: > > > On Wed, 29 Jan 2025 12:02:09 +1100 > > > David Gibson wrote: > > > =20 > > > > On Tue, Jan 28, 2025 at 07:48:33AM +0100, Stefano Brivio wrote: =20 > > > > > On Tue, 28 Jan 2025 11:53:09 +1100 > > > > > David Gibson wrote: > > > > > =20 > > > > > > On Tue, Jan 28, 2025 at 12:15:28AM +0100, Stefano Brivio wrote:= =20 > > > > > > > Moving in_epoll out of the common flow data created a 7-bit h= ole in > > > > > > > struct tcp_splice_conn: repack by shrinking @flags by one (ot= herwise > > > > > > > unused) bit. =20 > > > > > >=20 > > > > > > Is this actually necessary for the migration stuff? Or just a = cleanup > > > > > > you spotted along the way? =20 > > > > >=20 > > > > > I thought it was helpful to keep the same size on 32-bit, but it = looks > > > > > like it's not actually needed. > > > > >=20 > > > > > Let me drop it from this series as it's just noise and I'm trying= to > > > > > keep this slim. If we are all happy with it I can apply it. If no= t I'll > > > > > forget about it. =20 > > > >=20 > > > > Eh, I don't care that much either way. > > > >=20 > > > > Note, btw, that bit-field packing is another way source and > > > > destination could potentially have mismatching data structures. II= UC > > > > bit field packing is described by the ABI and doesn't necessarily > > > > match the byte endianness. =20 > > >=20 > > > Right, that's actually the reason that brought me to this change: I w= as > > > comparing stuff between x86_64 and armv6l. On the other hand, this pa= rt > > > of the specific ABI is generally considered stable so I can rely on i= t. =20 > >=20 > > Uhh.. a specific ABI is stable, yes, but IIUC the whole point of these > > endian, word size etc. checks is that you're not counting on it being > > an identical ABI at each end. >=20 > Of course. I'm just saying that I can *rely on ABIs*. Not on them being > the same. >=20 > > I'm saying the bit field packing is another way the ABIs at each end > > could differ >=20 > It does. >=20 > > which is not currently accounted for. >=20 > That's because I have two hands, but obviously if I'm comparing ABIs... Ok, fair enough. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --LrhfTmPmiOrbS1qG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmebKc0ACgkQzQJF27ox 2GdYCw/9Et0m1ojpgUol6v//pofTTkoVpiJtG9kFrKMS4dL/WrRCmBZnn+fjmaiB tyec319VgbZ5URBgvJ9R06/bR+go8scuRBfKWwGns/dZXQwfO0AVDNDaQubvCK2J YZmOnE2PJZT9hcMkHnYxS/32DYepbqirLpA3kZyBGcX/Vz5GsWry4xoXjXAlvOdf naSRmuueElbC/AdYEyLVAg1L2jMJCU0yNIU9+Vup54haTREcR2oHmJ9uxKOJBGrz WsAPFHjaRFWjxJqF/hPNWmVr8ts8sR4Qv3mWqe5x4OhTsgCLX59sfiQlvtfNm6R2 4xEofHVmpdaCZuHQRlFA9KT9z6Yh5WgP5Bg8U64K0T7iZstT8PK3Zq6E4mPNqdWT 15VKRuR+6MaxQHkIWjVTdpr17eUiH2LS2JK8U1vpi7OttdLxx1SEdZbPE0RKGIzN bjtUOOFSvnRGBhrxX/ysdyPVjTHaLazWLomx9l8gOfAx3jG2/5ctgSZ6GeWhhgmv xUD0RgiHXFJXTUEbBB5Lcv0K/Ug6+pmsdiep56fACzC298pxkZV7EJZvyi38+nIq 132BPnSOxDD3ZjsvPuyZSQx79EUqltXknIS5FNbCatM/HVjlo91pb4xr23X3A1I+ o0nY0zd+mO+Rm5hQGwYYNt4QevASThQ6RpWaRRWLa4yqdtmBM6w= =saRO -----END PGP SIGNATURE----- --LrhfTmPmiOrbS1qG--