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=YJmSzqep; 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 08FBC5A061E for ; Thu, 30 Jan 2025 05:55:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738212921; 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=aMq/kiF48TvrxUgoIfGadt+tRPVSuAEnzRhysYcz0Gs=; b=YJmSzqeposIynZRhBv12Z1AkOujmIQ+aNxMCuV6Jd7SiiXCG+mu9xHX70KLP9DFrwzxMVH 207q9lXoa68EyKWk+F+khl7HrpU662g0UPsjwVhcrzOFCF6/ZgExwc2y/dOk6Dn+qXG5gV aGcWZdxkckaplTQf71yP8LCZq/reQmY= 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-156-v1ZNMR6OOYG-JxrhnO3tfw-1; Wed, 29 Jan 2025 23:55:19 -0500 X-MC-Unique: v1ZNMR6OOYG-JxrhnO3tfw-1 X-Mimecast-MFC-AGG-ID: v1ZNMR6OOYG-JxrhnO3tfw Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4362f893bfaso1338735e9.1 for ; Wed, 29 Jan 2025 20:55:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738212918; x=1738817718; 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=aMq/kiF48TvrxUgoIfGadt+tRPVSuAEnzRhysYcz0Gs=; b=C5EgGDKzHV9lVZ81L8I7dTyLYlL33kAv/Ifya4cQLCs+tBnLK1CDo+vcuViFpRp4Y0 sKcSI+d3CRP0FdmAwR9qwiGXxnOdRN5ztJxc9PM+WLgK+4NVKTYKgA3LTzMTeMYRz6e3 vfVzR2mZN1V+DxGmZJ4OVgLyY/VOmZ7tsAYlwalH4hOS8pcPzMYmnSPCJrALzlTCWB7R zuy8agiCNeHOR4D9i1N64xORGtBw0jNwFxTY0C55feY3XZ/hNv03vG4OWh9sheINHMxi IdLE5nyaQHZG2z61bvJ00DQIju7D+wlgS90wIIz/T9LBYzzUtoP9cJsZidkAk+nmLtTb WxsA== X-Gm-Message-State: AOJu0YyO2Uxb1WFJH53qpUvXYG5Pa+JhYVFhZ27iWCnacX91sbsIOmii a+gtHqbEqG2s9XCiQ7e5AEMV4rlGnFnNzsNhk61IcleBu4ZPn330HOU/VBjbjbp2bVegAYW7gL5 CM09AyWEbQgj3YSRhcSNYEMZgqMnQUomgekKiPNDVnHDLyLI4+A== X-Gm-Gg: ASbGncsuPtyzeizsr2dxcUkRc+KrNJjR+rSy1+V8E76gVUaQoC3exU+Pn0JwQPGEAw5 TIBRGBtBJHj0MUfWo9H8GydfxyLzP/JThsT4wmIsO9rNEJZ+NTBXPxaV4X4l2alruM+WJIL5xXQ vgGNW/Y21YAdNfN+3tntGoaEWU6xqbPI/zuLfXlRqdKp80TsvU1K3nrbsiD9lg+umHNGiKLWleC h710Kp6VSsvsHJGnGH83naQ9/u0NojEMNVvw5B2q/AHgsZjoEeJLcswPuztveYUWmWXIAOt6bmc YABAVkns1/FkbNz8 X-Received: by 2002:a05:600c:b89:b0:438:a240:c54 with SMTP id 5b1f17b1804b1-438dc3ae14bmr43367655e9.9.1738212917708; Wed, 29 Jan 2025 20:55:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IEJOUMBV06CWx3hhx7jCrqqeLzrDy+VN+B864w1kOHnba9IGm1AXmiZGwC5Ugh8OIRVrzlJAA== X-Received: by 2002:a05:600c:b89:b0:438:a240:c54 with SMTP id 5b1f17b1804b1-438dc3ae14bmr43367565e9.9.1738212917383; Wed, 29 Jan 2025 20:55:17 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438dcc2ede0sm44551945e9.21.2025.01.29.20.55.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2025 20:55:16 -0800 (PST) Date: Thu, 30 Jan 2025 05:55:00 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 3/7] tcp_conn: Avoid 7-bit hole in struct tcp_splice_conn Message-ID: <20250130055500.0d14a3d5@elisabeth> In-Reply-To: References: <20250127231532.672363-1-sbrivio@redhat.com> <20250127231532.672363-4-sbrivio@redhat.com> <20250128074833.716e4a66@elisabeth> <20250129083340.38926745@elisabeth> 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: jL3SJiSfUjcunjLQOY0e-zZcFhKRdodfjo5QMrLs8q4_1738212918 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: XPV65POD2IM3K6JKNJWZZPG6PL4PACLG X-Message-ID-Hash: XPV65POD2IM3K6JKNJWZZPG6PL4PACLG 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, 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: On Thu, 30 Jan 2025 11:44:19 +1100 David Gibson wrote: > 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: > > > > > On Tue, Jan 28, 2025 at 07:48:33AM +0100, Stefano Brivio wrote: > > > > On Tue, 28 Jan 2025 11:53:09 +1100 > > > > David Gibson wrote: > > > > > > > > > On Tue, Jan 28, 2025 at 12:15:28AM +0100, Stefano Brivio wrote: > > > > > > Moving in_epoll out of the common flow data created a 7-bit hole in > > > > > > struct tcp_splice_conn: repack by shrinking @flags by one (otherwise > > > > > > unused) bit. > > > > > > > > > > Is this actually necessary for the migration stuff? Or just a cleanup > > > > > you spotted along the way? > > > > > > > > I thought it was helpful to keep the same size on 32-bit, but it looks > > > > like it's not actually needed. > > > > > > > > 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 not I'll > > > > forget about it. > > > > > > Eh, I don't care that much either way. > > > > > > Note, btw, that bit-field packing is another way source and > > > destination could potentially have mismatching data structures. IIUC > > > bit field packing is described by the ABI and doesn't necessarily > > > match the byte endianness. > > > > Right, that's actually the reason that brought me to this change: I was > > comparing stuff between x86_64 and armv6l. On the other hand, this part > > of the specific ABI is generally considered stable so I can rely on it. > > 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. Of course. I'm just saying that I can *rely on ABIs*. Not on them being the same. > I'm saying the bit field packing is another way the ABIs at each end > could differ It does. > which is not currently accounted for. That's because I have two hands, but obviously if I'm comparing ABIs... -- Stefano