From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 55CEA22538F for ; Sun, 5 Apr 2026 03:30:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775359813; cv=none; b=BIdo6E92URG7BnRrX5hUveh09mGQI6AXOXaZz7WjZkBSRqUM2jOeXTfPLdrzgux2xmWANYro7fCtoupw4d33kPvCvRkAilZpeznvB6315tcOm81cu9UBhaAgDM2R8bBqsml1BJdJvTL/gb9+W5xRjzfVgeniQCLRWO0PmkbzQLI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775359813; c=relaxed/simple; bh=6VgXMf1dbZIEFJ+BoZ7O6EwYBpyyfjLk5p6wRIkkWvU=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=s6F5L4pSJiGr5egEhpj2xSmKZhcM5ST1QPWoNfKCyEMuz4CQ5gIF5nrLrSFjm7rO83f+D9a4qHOfhZj2royVzUhlvX8eOmF4HGFxYrnLlHdR4XnRpIgIgnb3//yTOdxG3u9i88gBxUiz3CtZfsxK/Uw1t35g8ljOor9iW76d+dc= 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=OqCn98GQ; arc=none smtp.client-ip=209.85.128.170 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="OqCn98GQ" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-79f855b2575so28541267b3.2 for ; Sat, 04 Apr 2026 20:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775359810; x=1775964610; 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=rIhyqVeQcmo1jb/qAoAPSAYd8D2Hnw0/pgPPvAap7Ok=; b=OqCn98GQWDz9jI20hI4x9a44Il9r2ZNPJKo0lCvR+piaBWaH1uxYHEu53ikpOMNBxl VJGcbOKCGB8gQkzqRzK5PBi2g5FkkE4fjDWBQayLLMt5DmXr8CwUV7u4TapgSBl9wvQJ AE/1ROUDrWuSs/R++4EN4BjAsNu6G+7SKM8XCDSctAqLGfl51PsCp7sQqwBLvm6gAHfH /CRlRThl58sA7kH9NZIYYuM/uStCQTSnHa5rez+1QIFULRNb2vwD52X2+GLN+U4w7Ojd ryMnrkP9Nyoaoat8hg+3AJLMGYXPOroo0Mtz+7yiqXdVFSHVhnsKdEz4NB66i9aFgGpo zC8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775359810; x=1775964610; 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=rIhyqVeQcmo1jb/qAoAPSAYd8D2Hnw0/pgPPvAap7Ok=; b=q1iUExUFqn07CS1LVH3Hl+smrPufz7sWr3UcgElvpz0eytQNlIHOD4VwcjLctDQUsY dM8CdNsZjRUifUHuK+WjtEJOgQX8QBqLeFju4VPT/5ZWdy8HOQZb3Oki2VD9+GCrGkvn HJnR8cY2QB96/v0+lf4FU4ppUqfxZVKCMV5kPccdG8Pc/SLoXk93tt5Eiyexx1jWG4eT y8LNe9pjT5gMdaMs9ZdQNoEY3DnE1zSR2foL3leog9uMnTuGNGxEgdorA5yqvKW1zrgu egm1wYSb09pUD0Ba7/H3kahOYjGldnShcEbEuFVJsMFTG2Nbf7f266rriVZn3E4JNMtb GwSw== X-Forwarded-Encrypted: i=1; AJvYcCVV0/9y/M0EGknccffD4XfBuWjAx6SJ8I2ARFH6bw+mMli/JCalTYaW/XAmrQ4uZHkSJcd4VX982IN1g/8=@vger.kernel.org X-Gm-Message-State: AOJu0YzCmK3ROMp1tsjKeZwC5QWJgiVijIG9pejlW7Qeb3CcBFPxGJXm sSJqSxTtLYUygXqtPDVqZJcd68TWrdt7WQ64k05nejntQqmNRhoJCSpJ X-Gm-Gg: AeBDiesGNHXloqMZRqPYj9qn4C0JY6z5P1kEueRvhKjO8f3njpGU9mHdGZ+JVnLTVqF 2sFMArFfOKcMXNq+MTCmffzufVtFfTZkInlHifo84wQwgQW1y0cCl4eZRJxApLYjhg+dJP/+mCm pSlte490PIqK4E3VkIOgukqdV51BvrhQUwlMtTfZa5KQRKpjZqXLcFuDwFFAlknYDQhmJ05QYvR C9vfRfCOC7YlUkeptmjsQltTz19YQOtd0hmRVRAKKSbgEN2f8VrveUY5mOxoC/ndnvqsdCKc6bJ u3PsfvM1MMtKIovlfkpseC/DOb9W5ei47Fvx2A/HZ/TFAI6zkBFFmo+WEYzwjtIesByD4ncvCDF 3vhdz0mYq0ARQ+l8+FHONr1mDCg3lQXCKmN3m2pRekaQapSaANt3GcvpMT4dU/aRq3e5DvhJmQX MfJht8OUr/Q8YUcu5qFDB+LXXTQJUcOpNtsejvceGyI/NSN0NZ9Sj3ImuEKepF4jJfvgBrbJm9U /qZ X-Received: by 2002:a05:690c:660a:b0:79a:5ad7:b9ae with SMTP id 00721157ae682-7a4d61558demr90426747b3.42.1775359810385; Sat, 04 Apr 2026 20:30:10 -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-7a36ea2872esm38036227b3.19.2026.04.04.20.30.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Apr 2026 20:30:09 -0700 (PDT) Date: Sat, 04 Apr 2026 23:30:09 -0400 From: Willem de Bruijn To: Willem de Bruijn , Joe Damato , netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , dalias@libc.org Cc: andrew+netdev@lunn.ch, linux-kernel@vger.kernel.org, willemb@google.com, Joe Damato , 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 Willem de Bruijn wrote: > Joe Damato wrote: > > Extend the packet socket selftest, adding a recvmsg path, to test > > PACKET_AUXDATA. Check basic attributes of tpacket_auxdata. > > > > Signed-off-by: Joe Damato > > --- > > tools/testing/selftests/net/psock_snd.c | 67 ++++++++++++++++++++++-- > > tools/testing/selftests/net/psock_snd.sh | 5 ++ > > 2 files changed, 67 insertions(+), 5 deletions(-) > > > > v2: > > - Add is_psock bool argument to do_rx. > > - Factor out aux data check into its own function for readability. > > > > diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c > > index 81096df5cffc..5464317c1764 100644 > > --- a/tools/testing/selftests/net/psock_snd.c > > +++ b/tools/testing/selftests/net/psock_snd.c > > @@ -40,6 +40,7 @@ static bool cfg_use_qdisc_bypass; > > static bool cfg_use_vlan; > > static bool cfg_use_vnet; > > static bool cfg_drop; > > +static bool cfg_aux_data; > > > > static char *cfg_ifname = "lo"; > > static int cfg_mtu = 1500; > > @@ -279,11 +280,54 @@ static int setup_rx(void) > > return fd; > > } > > > > -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. > Indeed I can trigger this, e.g., with ipv6_flowlabel.c with > > - char control[CMSG_SPACE(sizeof(flowlabel))] = {0}; > + char control[1 + CMSG_SPACE(sizeof(flowlabel))] = {0}; > > - cm = (void *)control; > + cm = (void *)control + 1; > > and compiling with -fsanitize=alignment. That triggers warnings for > all fields, starting from cmsg_len on line 78. > > In practice this does not cause issues, because the compiler appears > to align char[] to 16B, even though __alignof__(control) shows 1. This > seems true for x86_64, but I am not aware that it is true across all > archs, especially those that cannot handle unaligned access. > > I think the x86_64 source is the AMD64 ABI Draft, e.g., v 0.99.6 > > An array uses the same alignment as its elements, except that > a local or global array variable of length at least 16 bytes > or a C99 variable-length array variable always has alignment > of at least 16 bytes(4) > > (4) The alignment requirement allows the use of SSE instructions > when operating on the array. [..] > > Makes sense as sizeof struct cmsghdr == 16. > > cmsg_len has length 8 (size_t). We'll be hardpressed to find a > CMSG_DATA example with a larger alignment requirement. Indeed I did > not in this directory. So satisfying 8-byte alignment for msg_control > will suffice for all tests in this directory. > > Unless we're certain that 8B alignment for stack aligned char[] is > guaranteed across platforms, one safe approach it to add explicit > alignment: > > - char control[CMSG_SPACE(sizeof(flowlabel))] = {0}; > + char control[CMSG_SPACE(sizeof(flowlabel))] __attribute__((aligned(8))) = {0}; > > I can update the (other) tests. Unless someone knows that this is > indeed not needed in practice on any platform. > > > + > > + if (adata->tp_net != ETH_HLEN) > > + error(1, 0, "cmsg tp_net != ETH_HLEN"); > > + > > + if (adata->tp_len != expected_len) > > + error(1, 0, "cmsg tp_len != %u", expected_len); > > + > > + if (adata->tp_snaplen != expected_len) > > + error(1, 0, "cmsg tp_snaplen != %u", expected_len); > > +} > > + > > +static void do_rx(int fd, int expected_len, char *expected, bool is_psock) > > +{ > > + bool aux = is_psock && cfg_aux_data; > > + char cmsg_buf[1024] = {}; > > + struct msghdr msg = {}; > > + struct iovec iov[1]; > > int ret; > > > > - ret = recv(fd, rbuf, sizeof(rbuf), 0); > > + if (aux) { > > + iov[0].iov_base = rbuf; > > + iov[0].iov_len = sizeof(rbuf); > > + > > + msg.msg_iov = iov; > > + msg.msg_iovlen = 1; > > + > > + msg.msg_control = cmsg_buf; > > + msg.msg_controllen = sizeof(cmsg_buf); > > + > > + ret = recvmsg(fd, &msg, 0); > > + } else { > > + ret = recv(fd, rbuf, sizeof(rbuf), 0); > > + } > > +