netdev - Re: [PATCH net-next 1/4] vxlan: Join / leave MC group after remote changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aa210895-61d0-468d-b902-93451983756b@redhat.com>
Date: Tue, 11 Feb 2025 16:52:40 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Petr Machata <petrm@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 netdev@...r.kernel.org, Ido Schimmel <idosch@...dia.com>, mlxsw@...dia.com,
 Andrew Lunn <andrew+netdev@...n.ch>,
 Nikolay Aleksandrov <razor@...ckwall.org>, Roopa Prabhu <roopa@...dia.com>,
 Menglong Dong <menglong8.dong@...il.com>, Guillaume Nault <gnault@...hat.com>
Subject: Re: [PATCH net-next 1/4] vxlan: Join / leave MC group after remote
 changes

On 2/11/25 3:56 PM, Petr Machata wrote:
> Paolo Abeni <pabeni@...hat.com> writes:
>> On 2/7/25 6:34 PM, Petr Machata wrote:
>>> @@ -3899,6 +3904,11 @@ static void vxlan_config_apply(struct net_device *dev,
>>>  			dev->mtu = conf->mtu;
>>>  
>>>  		vxlan->net = src_net;
>>> +
>>> +	} else if (vxlan->dev->flags & IFF_UP) {
>>> +		if (vxlan_addr_multicast(&vxlan->default_dst.remote_ip) &&
>>> +		    rem_changed)
>>> +			vxlan_multicast_leave(vxlan);
>>
>> AFAICS vxlan_vni_update_group() is not completely ignore
>> vxlan_multicast_{leave,join} errors. Instead is bailing out as soon as
>> any error happens. For consistency's sake I think it would be better do
>> the same here.
>>
>> Also I have the feeling that ending-up in an inconsistent status with no
>> group joined would be less troublesome than the opposite.
> 
> This can already happen FWIW. If you currently want to change the remote
> group address in a way that doesn't break things, you take the netdevice
> down, then change it, then bring it back up. The leave during downing
> can fail and will not be diagnosed. (Nor can it really be, you can't
> veto downing.)

I see.

> I can add the bail-outs that you ask for, but I don't know that there is
> a way to resolve these issues for real.

The main point I made was about consistency: making the
vxlan_config_apply() behavior as close as possible to
vxlan_vni_update_group() as stated in the commit message.

Cheers,

Paolo