[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e811259e74177870349459ae1a4342001e6f4e5a.camel@mandelbit.com>
Date: Fri, 14 Nov 2025 15:43:55 +0100
From: Ralf Lici <ralf@...delbit.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Jakub Kicinski <kuba@...nel.org>, Antonio Quartulli
<antonio@...nvpn.net>, netdev@...r.kernel.org, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 3/8] ovpn: notify userspace on client float
event
On Fri, 2025-11-14 at 15:22 +0100, Sabrina Dubroca wrote:
> 2025-11-14, 10:26:31 +0100, Ralf Lici wrote:
> > On Thu, 2025-11-13 at 18:21 -0800, Jakub Kicinski wrote:
> > > On Tue, 11 Nov 2025 22:47:36 +0100 Antonio Quartulli wrote:
> > > > + if (ss->ss_family == AF_INET) {
> > > > + sa = (struct sockaddr_in *)ss;
> > > > + if (nla_put_in_addr(msg,
> > > > OVPN_A_PEER_REMOTE_IPV4,
> > > > + sa->sin_addr.s_addr) ||
> > > > + nla_put_net16(msg, OVPN_A_PEER_REMOTE_PORT,
> > > > sa-
> > > > > sin_port))
> > > > + goto err_cancel_msg;
> > > > + } else if (ss->ss_family == AF_INET6) {
> > > > + sa6 = (struct sockaddr_in6 *)ss;
> > > > + if (nla_put_in6_addr(msg,
> > > > OVPN_A_PEER_REMOTE_IPV6,
> > > > + &sa6->sin6_addr) ||
> > > > + nla_put_u32(msg,
> > > > OVPN_A_PEER_REMOTE_IPV6_SCOPE_ID,
> > > > + sa6->sin6_scope_id) ||
> > > > + nla_put_net16(msg, OVPN_A_PEER_REMOTE_PORT,
> > > > sa6->sin6_port))
> > > > + goto err_cancel_msg;
> > > > + } else {
> > >
> > > presumably on this branch ret should be set to something?
> >
> > You're right, otherwise it would return -EMSGSIZE which is not what
> > we
> > want here.
>
> But that should never happen with the current code, since
> ovpn_nl_peer_float_notify is only called by ovpn_peer_endpoints_update
> when salen != 0, and in that case we can only have ss_family = AF_INET
> or ss_family = AF_INET6? (and otherwise it'd be an unitialized value
> from ovpn_peer_endpoints_update)
>
> (no objection to making ovpn_nl_peer_float_notify handle that
> situation better in case it grows some other callers/contexts)
True, with the current code we can't reach that branch. But as you
noted, if the calling context evolves, we're already covered and IMHO
the cost of handling this case right now is negligible.
--
Ralf Lici
Mandelbit Srl
Powered by blists - more mailing lists