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] [day] [month] [year] [list]

Message-ID: <87o6z8rv0h.fsf@nvidia.com>
Date: Tue, 11 Feb 2025 23:11:18 +0100
From: Petr Machata <petrm@...dia.com>
To: Paolo Abeni <pabeni@...hat.com>
CC: Petr Machata <petrm@...dia.com>, "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


Paolo Abeni <pabeni@...hat.com> writes:

> 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.

No problem, I'll send a v2.