From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: "Simon Horman" <horms@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Akihiko Odaki" <akihiko.odaki@daynix.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH][next] virtio_net: Fix alignment and avoid -Wflex-array-member-not-at-end warning
Date: Thu, 4 Sep 2025 17:31:32 -0400 [thread overview]
Message-ID: <20250904172951-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <cac19beb-eefb-4a6a-9eec-b414199ce339@embeddedor.com>
On Thu, Sep 04, 2025 at 08:53:31PM +0200, Gustavo A. R. Silva wrote:
>
>
> On 9/4/25 11:13, Simon Horman wrote:
> > On Wed, Sep 03, 2025 at 09:36:13PM +0200, Gustavo A. R. Silva wrote:
> > > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> > > getting ready to enable it, globally.
> > >
> > > Use the new TRAILING_OVERLAP() helper to fix the following warning:
> > >
> > > drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > >
> > > This helper creates a union between a flexible-array member (FAM)
> > > and a set of members that would otherwise follow it (in this case
> > > `u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This
> > > overlays the trailing members (rss_hash_key_data) onto the FAM
> > > (hash_key_data) while keeping the FAM and the start of MEMBERS aligned.
> > > The static_assert() ensures this alignment remains, and it's
> > > intentionally placed inmediately after `struct virtnet_info` (no
> > > blank line in between).
> > >
> > > Notice that due to tail padding in flexible `struct
> > > virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`
> > > (at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at
> > > offset 84 in struct virtnet_info) are misaligned by one byte. See
> > > below:
> > >
> > > struct virtio_net_rss_config_trailer {
> > > __le16 max_tx_vq; /* 0 2 */
> > > __u8 hash_key_length; /* 2 1 */
> > > __u8 hash_key_data[]; /* 3 0 */
> > >
> > > /* size: 4, cachelines: 1, members: 3 */
> > > /* padding: 1 */
> > > /* last cacheline: 4 bytes */
> > > };
> > >
> > > struct virtnet_info {
> > > ...
> > > struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */
> > >
> > > /* XXX last struct has 1 byte of padding */
> > >
> > > u8 rss_hash_key_data[40]; /* 84 40 */
> > > ...
> > > /* size: 832, cachelines: 13, members: 48 */
> > > /* sum members: 801, holes: 8, sum holes: 31 */
> > > /* paddings: 2, sum paddings: 5 */
> > > };
> > >
> > > After changes, those members are correctly aligned at offset 795:
> > >
> > > struct virtnet_info {
> > > ...
> > > union {
> > > struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */
> > > struct {
> > > unsigned char __offset_to_hash_key_data[3]; /* 792 3 */
> > > u8 rss_hash_key_data[40]; /* 795 40 */
> > > }; /* 792 43 */
> > > }; /* 792 44 */
> > > ...
> > > /* size: 840, cachelines: 14, members: 47 */
> > > /* sum members: 801, holes: 8, sum holes: 35 */
> > > /* padding: 4 */
> > > /* paddings: 1, sum paddings: 4 */
> > > /* last cacheline: 8 bytes */
> > > };
> > >
> > > As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also
> > > moved to the end, since it seems those three members should stick
> > > around together. :)
> > >
> > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > > ---
> > >
> > > This should probably include the following tag:
> > >
> > > Fixes: ed3100e90d0d ("virtio_net: Use new RSS config structs")
> > >
> > > but I'd like to hear some feedback, first.
> >
> > I tend to agree given that:
> >
> > On the one hand:
> >
> > 1) in virtnet_init_default_rss(), netdev_rss_key_fill() is used
> > to write random data to .rss_hash_key_data
> >
> > 2) In virtnet_set_rxfh() key data written to .rss_hash_key_data
> >
> > While
> >
> > 3) In virtnet_commit_rss_command() virtio_net_rss_config_trailer,
> > including the contents of .hash_key_data based on the length of
> > that data provided in .hash_key_length is copied.
> >
> > It seems to me that step 3 will include 1 byte of uninitialised data
> > at the start of .hash_key_data. And, correspondingly, truncate
> > .rss_hash_key_data by one byte.
> >
> > It's unclear to me what the effect of this - perhaps they key works
> > regardless. But it doesn't seem intended. And while the result may be
> > neutral, I do suspect this reduces the quality of the key. And I more
> > strongly suspect it doesn't have any positive outcome.
> >
> > So I would lean towards playing it safe and considering this as a bug.
> >
> > Of course, other's may have better insight as to the actual effect of this.
>
> Yeah, in the meantime I'll prepare v2 with both the 'Fixes' and 'stable'
> tags.
>
> Thanks for the feedback!
> -Gustavo
>
>
I agree. It looks like that commit completely broke RSS
configuration. Akihiko do you mind sharing how that was
tested? Maybe help testing the fix? Thanks!
next prev parent reply other threads:[~2025-09-04 21:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 19:36 [PATCH][next] virtio_net: Fix alignment and avoid -Wflex-array-member-not-at-end warning Gustavo A. R. Silva
2025-09-04 9:13 ` Simon Horman
2025-09-04 18:53 ` Gustavo A. R. Silva
2025-09-04 21:31 ` Michael S. Tsirkin [this message]
2025-09-04 21:32 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250904172951-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=gustavo@embeddedor.com \
--cc=gustavoars@kernel.org \
--cc=horms@kernel.org \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).