From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B20C303A37 for ; Mon, 6 Apr 2026 20:56:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775509020; cv=none; b=EsmD81QGuwBC8DS55/cAIsYx0kZCFDU68BuQ+hNvd9PovmuHSrxngu7vKMb9qvy1mAYvpQV5YXPiXt30y88BBfZXQYV3Jtv+D37s1wnqJs96mHMBM+m8iCJZ9k9W5JeHx/SPK4UYQHdxfg5TTEAXqKAF2niaAnFRiygz5Ho1z0I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775509020; c=relaxed/simple; bh=z9ymFt/yV556ogk1/KubQwbpDGG7ebWj5Z0TkeYOemM=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=uT5WOe3RKflFMW0vgSfzKP/FmtC/6Zw5/6moP610G+IcY5p1bJKNlAegHddLTGY8nw81xBjIqHQdiRx8kPiJBkFbLRvB6WgyeycLMNMBVAaErdZfSmvyJByYoPAsjP9EyH5QOWlJZWo47Dy9I+roO6MGqvSTR7XyGSNfyVQZQTQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=o6jHBOC0; arc=none smtp.client-ip=209.85.128.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="o6jHBOC0" Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-79495b1aaa7so40129317b3.1 for ; Mon, 06 Apr 2026 13:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775509018; x=1776113818; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=IbeQ7RU4fPJs1XWunFP2puvppP11EJLLY6x9wM0vzAs=; b=o6jHBOC0fjoX+xJ71qHYrnNLP60bB/b2cAuzOK0LiwgDY7zJtA91Ei8uJrwjIIwDy0 Pn9epCKoLMraOtBvX2nqUnJb1uEfpQd9j6Ny4IKQLvpPYuHGjRfjOMUL6k65cB8rQLb8 rLuvRtqHm306aLDziIPaMf/jrwnwLkR1UrRcTBGNq+rj1Zg/rVsNKj5m5oCMguRiZK/N WpeCD9ScMX7qoRYhPmEDtQIW23iETpKSoR9IudnkSUeo0a8ySafMigAryVRG4H/SWM0d mtJAJXR4REjaPuU+NtvHjfpKEwDYGSPD+Gd/fFq6tHRIL+bQPe8xyJ2nKFYZNC7Y7CiF Iy6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775509018; x=1776113818; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IbeQ7RU4fPJs1XWunFP2puvppP11EJLLY6x9wM0vzAs=; b=DERGf7VHOE5EPDq8HOz45UZ115o88XqYrS+XeFR8ggP+gV9y6//t/5lT0BvWAyulfi JA2SNEgNCACGeP6V+O4F8rGflgxcqEdZB0frQax6pPuclZgGdUbjFo4VdXvQGMAg39WT rvXoiTP9HSGUCzSW4ABlrhvnooheC9WYUpCti6S0uttb98FBYvGNrhknwGCo09UyKAfa c3iUnxj1kX34Bl1IGeXpY5dLDAO2Eb05LdMQGoBuBtl5bXn6ZjOUYAnQAtV+BcAKkm3D oHI4MQF4Tc4QdBJCasRE8n8wsMpPCLzbvg7FWqGdVXOoQH30QebskQfHsQBAtWgSqk+f KHrg== X-Forwarded-Encrypted: i=1; AJvYcCUq8sFGcx5KXWp7lsd9S6lrtFGDig5rG9qY2o4RGRKG/wvm1NvpU8tKOZOg3cuO7MN0qy/uU2fJg38w7ZE=@vger.kernel.org X-Gm-Message-State: AOJu0YysoaA2TLjuKC1ggiTswbLQbgkUj2BdP93fhrEAyobC8lYUoxDq F5+RIhiqUlMKOVmH3bOS1gTdnq+ApFZk3wBOrA9Jyr1/52R+SClsRgMn X-Gm-Gg: AeBDieuPPxPH8rwBMsTkdpcP9Yq7bLeN1W8I9B/yk3HwlfQ8Es4uKpL+1u529YRJAfK WSmQFXAn7wukPKvdBMvuQdQ8T6v0j9QkLevpdi581odWTajT5Sp3RJattE9M4mJxHpGyuEIw5xE LXD1tBd+Mwb7tB51THfhbIJS8bVrifHnzOnoJI8/0/A0nueslXvzlAh+wu6CbfCrEYeC49aKJBg mqu24GJbXGnSkrqFTxn3qGsG93IEov4LyToP1fRLhMbnxw5/P8B6QN3Vy3aOdm1Gy6qFFUElkIG bAC9LgtPpfyqDwFlsyVCz7NikyqxG1dcd3RKTdULPtw2Y9oXrkG7ZbrfXvvJ+4tcUvZ5Obd88kR gfpR2pS9pmWg6pPH/SKeNrmBsroh/vhvui4xY12YafgfEemjz2XAmgKanTsXAqOp8AztMAUMq5F lyVMwJcmIVuUQVP2Dpza8qCDfm5GudJdxGnf85znJ26yme5MDn62sdcthEnIbCKNgx0Bv1i5Qlz 3Ymz9KOL1PVkoQ= X-Received: by 2002:a05:690c:38a:b0:79a:7cff:7b81 with SMTP id 00721157ae682-7a4d556cdf1mr149463227b3.27.1775509018352; Mon, 06 Apr 2026 13:56:58 -0700 (PDT) Received: from gmail.com (172.165.85.34.bc.googleusercontent.com. [34.85.165.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7a36e42fec3sm58182407b3.4.2026.04.06.13.56.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2026 13:56:57 -0700 (PDT) Date: Mon, 06 Apr 2026 16:56:56 -0400 From: Willem de Bruijn To: Joe Damato , Willem de Bruijn Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , dalias@libc.org, andrew+netdev@lunn.ch, linux-kernel@vger.kernel.org, willemb@google.com, linux-kselftest@vger.kernel.org Message-ID: In-Reply-To: References: <20260403233240.178948-1-joe@dama.to> <20260403233240.178948-4-joe@dama.to> Subject: Re: [net-next v2 3/3] selftests/net: Test PACKET_AUXDATA Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Joe Damato wrote: > On Sat, Apr 04, 2026 at 11:30:09PM -0400, Willem de Bruijn wrote: > > Willem de Bruijn wrote: > > > Joe Damato wrote: > > [...] > > > > > -static void do_rx(int fd, int expected_len, char *expected) > > > > +static void check_aux_data(struct cmsghdr *cmsg, int expected_len) > > > > { > > > > + struct tpacket_auxdata *adata; > > > > + > > > > + if (!cmsg) > > > > + error(1, 0, "auxdata null"); > > > > + > > > > + if (cmsg->cmsg_level != SOL_PACKET) > > > > + error(1, 0, "cmsg_level != SOL_PACKET"); > > > > + > > > > + if (cmsg->cmsg_type != PACKET_AUXDATA) > > > > + error(1, 0, "cmsg_type != PACKET_AUXDATA"); > > > > + > > > > + adata = (struct tpacket_auxdata *)CMSG_DATA(cmsg); > > > > > > Sashiko had another interesting observation that this access may be > > > unaligned, as cmsg_buf[1024] has 1-byte alignment. > > > > > > That is not new in this patch. Indeed most tests in this dir just > > > deference msg_control as struct cmsghdr * and CMSG_DATA as whatever > > > domain specific type. > > > > > > The man page also warns about this and suggests using memcpy to > > > access CMSG_DATA. Not sure why it does not warn about the other > > > cmsg_.. fields. > > > > The commit that introduced that has more context > > > > https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man/man3/cmsg.3?id=36d25246b4333513fefdbec7f78f29d193cf5d9a > > > > It points out 32-bit platforms where cmsghdr is 12 bytes. > > > > At least one example given, ptpd, uses a union to ensure alignment > > > > union { > > struct cmsghdr cm; > > char control[256]; > > } cmsg_un; > > > > But at least one other example, ssmping, does not. So I think not even > > the 4B (on 32-bit archs) of cmsghdr fields can be depended on. > > I'm fine with adding an "__attribute__((aligned(8)))" to be safe, but FWIW, I > think the key point from the commit message linked above is: > > shows access to int payload via *(int *)CMSG_DATA(cmsg) (of course > int is safe because its alignment is <= header alignment, but this > is not mentioned). But that conditional on having a union as showed to make sure that the structure has the struct cmsghdr alignment. A bare char[] won't have that. Anyway, in practice on the platforms we test this hasn't been an issue. Fine to copy the example from other tests, leaving out the alignment. I will follow-up with one patch to update all of them at once, once I'm certain that I did not overlook some other mechanism that implicitly does guarantee this alignment on all platforms. > struct tpacket_auxdata only has u32 and u16, so 4 byte alignment seems fine > and I don't think the issue applies in this particular case. But, as I said > above, I am fine with adding the attribute to be defensive.