From: Jakub Kicinski <kuba@kernel.org>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
Johannes Berg <johannes@sipsolutions.net>,
David Ahern <dsahern@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, Kees Cook <kees@kernel.org>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH v2 1/4][next] uapi: socket: Introduce struct sockaddr_legacy
Date: Thu, 31 Oct 2024 18:01:45 -0700 [thread overview]
Message-ID: <20241031180145.01e14e38@kernel.org> (raw)
In-Reply-To: <23bd38a4bf024d4a92a8a634ddf4d5689cd3a67e.1729802213.git.gustavoars@kernel.org>
On Thu, 24 Oct 2024 15:11:24 -0600 Gustavo A. R. Silva wrote:
> + * This is the legacy form of `struct sockaddr`. The original `struct sockaddr`
> + * was modified in commit b5f0de6df6dce ("net: dev: Convert sa_data to flexible
> + * array in struct sockaddr") due to the fact that "One of the worst offenders
> + * of "fake flexible arrays" is struct sockaddr". This means that the original
> + * `char sa_data[14]` behaved as a flexible array at runtime, so a proper
> + * flexible-array member was introduced.
This isn't spelled out in the commit messages AFACT so let me ask..
Why aren't we reverting b5f0de6df6dce, then?
Feels like the best solution would be to have a separate type with
the flex array to clearly annotate users who treat it as such.
Is that not going to work?
My noob reading of b5f0de6df6dce is that it was a simpler workaround
for the previous problem, avoided adding a new type (and the conversion
churn). But now we are adding a type and another workaround on top.
Sorry if I'm misunderstanding. No question that the struct is a mess,
but I don't feel like this is helping the messiness...
next prev parent reply other threads:[~2024-11-01 1:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 21:07 [PATCH v2 0/4][next] net: Avoid thousands of -Wflex-array-member-not-at-end warnings Gustavo A. R. Silva
2024-10-24 21:11 ` [PATCH v2 1/4][next] uapi: socket: Introduce struct sockaddr_legacy Gustavo A. R. Silva
2024-10-28 20:38 ` Andrew Lunn
2024-10-28 20:47 ` Johannes Berg
2024-10-28 23:40 ` Kees Cook
2024-10-28 23:31 ` Kees Cook
2024-10-28 23:34 ` Kees Cook
2024-11-01 1:01 ` Jakub Kicinski [this message]
2024-11-04 3:43 ` Kees Cook
2024-10-24 21:12 ` [PATCH v2 2/4][next] uapi: wireless: Avoid -Wflex-array-member-not-at-end warnings Gustavo A. R. Silva
2024-10-28 23:35 ` Kees Cook
2024-10-24 21:13 ` [PATCH v2 3/4][next] uapi: net: arp: " Gustavo A. R. Silva
2024-10-28 23:35 ` Kees Cook
2024-10-24 21:14 ` [PATCH v2 4/4][next] uapi: net: " Gustavo A. R. Silva
2024-10-28 23:37 ` Kees Cook
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=20241031180145.01e14e38@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=horms@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).