From: Sabrina Dubroca <sd@queasysnail.net>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
David Ahern <dsahern@kernel.org>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH net-next v2 2/5] udp_tunnel: fix compile warning
Date: Fri, 21 Mar 2025 18:11:09 +0100 [thread overview]
Message-ID: <Z92drSwwTq17kOMr@krikkit> (raw)
In-Reply-To: <67dd9556e1305_14b140294a7@willemb.c.googlers.com.notmuch>
2025-03-21, 12:35:34 -0400, Willem de Bruijn wrote:
> Paolo Abeni wrote:
> > Nathan reported that the compiler is not happy to use a zero
> > size udp_tunnel_gro_types array:
> >
> > net/ipv4/udp_offload.c:130:8: warning: array index 0 is past the end of the array (that has type 'struct udp_tunnel_type_entry[0]') [-Warray-bounds]
> > 130 | udp_tunnel_gro_types[0].gro_receive);
> > | ^ ~
> > include/linux/static_call.h:154:42: note: expanded from macro 'static_call_update'
> > 154 | typeof(&STATIC_CALL_TRAMP(name)) __F = (func); \
> > | ^~~~
> > net/ipv4/udp_offload.c:47:1: note: array 'udp_tunnel_gro_types' declared here
> > 47 | static struct udp_tunnel_type_entry udp_tunnel_gro_types[UDP_MAX_TUNNEL_TYPES];
> > | ^
> > 1 warning generated.
> >
> > In such (unusual) configuration we should skip entirely the
> > static call optimization accounting.
> >
> > Reported-by: syzbot+8c469a2260132cd095c1@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/netdev/cover.1741718157.git.pabeni@redhat.com/T/#m6e309a49f04330de81a618c3c166368252ba42e4
> > Fixes: 311b36574ceac ("udp_tunnel: use static call for GRO hooks when possible")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>
> Should CONFIG_NET_UDP_TUNNEL just not be user selectable and only
> enabled by implementations of UDP tunnels like vxlan and geneve?
It's already not user selectable?
config NET_UDP_TUNNEL
tristate
(no string after bool/tristate, so no manual config)
But there are tunnels that don't do GRO, so they're not counted in
UDP_MAX_TUNNEL_TYPES, and if only those types are enabled, we'll have
CONFIG_NET_UDP_TUNNEL=y with UDP_MAX_TUNNEL_TYPES == 0.
> > ---
> > net/ipv4/udp_offload.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 02365b818f1af..fd2b8e3830beb 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -83,7 +83,7 @@ void udp_tunnel_update_gro_rcv(struct sock *sk, bool add)
> > struct udp_sock *up = udp_sk(sk);
> > int i, old_gro_type_nr;
> >
> > - if (!up->gro_receive)
> > + if (!UDP_MAX_TUNNEL_TYPES || !up->gro_receive)
> > return;
>
> If that is too risky, I suppose this workaround is sufficient.
> But having a zero length array seems a bit odd.
I think the alternative would be to add
#if UDP_MAX_TUNNEL_TYPES > 0
around some of this code.
--
Sabrina
next prev parent reply other threads:[~2025-03-21 17:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 11:52 [PATCH net-next v2 0/5] udp_tunnel: GRO optimization follow-up Paolo Abeni
2025-03-21 11:52 ` [PATCH net-next v2 1/5] udp_tunnel: properly deal with xfrm gro encap Paolo Abeni
2025-03-21 16:33 ` Willem de Bruijn
2025-03-25 9:52 ` Paolo Abeni
2025-03-25 12:12 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 2/5] udp_tunnel: fix compile warning Paolo Abeni
2025-03-21 16:35 ` Willem de Bruijn
2025-03-21 17:11 ` Sabrina Dubroca [this message]
2025-03-25 16:09 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 3/5] udp_tunnel: fix UaF in GRO accounting Paolo Abeni
2025-03-21 16:39 ` Willem de Bruijn
2025-03-25 16:10 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 4/5] udp_tunnel: avoid inconsistent local variables usage Paolo Abeni
2025-03-21 16:39 ` Willem de Bruijn
2025-03-25 16:17 ` Sabrina Dubroca
2025-03-21 11:52 ` [PATCH net-next v2 5/5] udp_tunnel: prevent GRO lookup optimization for user-space sockets Paolo Abeni
2025-03-21 16:43 ` Willem de Bruijn
2025-03-25 16:22 ` Sabrina Dubroca
2025-03-25 16:24 ` [PATCH net-next v2 0/5] udp_tunnel: GRO optimization follow-up Jakub Kicinski
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=Z92drSwwTq17kOMr@krikkit \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemdebruijn.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.