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]
Date:   Tue, 26 Jan 2021 09:40:13 +0200
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     Hangbin Liu <liuhangbin@...il.com>, <netdev@...r.kernel.org>
CC:     Roopa Prabhu <roopa@...dia.com>,
        "David S . Miller" <davem@...emloft.net>,
        <bridge@...ts.linux-foundation.org>,
        Jarod Wilson <jarod@...hat.com>,
        "Jiri Pirko" <jiri@...nulli.us>, Ivan Vecera <ivecera@...hat.com>
Subject: Re: [PATCH net-next] bridge: Propagate NETDEV_NOTIFY_PEERS notifier

On 26/01/2021 06:09, Hangbin Liu wrote:
> After adding bridge as upper layer of bond/team, we usually clean up the
> IP address on bond/team and set it on bridge. When there is a failover,
> bond/team will not send gratuitous ARP since it has no IP address.
> Then the down layer(e.g. VM tap dev) of bridge will not able to receive
> this notification.
> 
> Make bridge to be able to handle NETDEV_NOTIFY_PEERS notifier.
> 
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> ---
>  net/bridge/br.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index ef743f94254d..b6a0921bb498 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -125,6 +125,7 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
>  		/* Forbid underlying device to change its type. */
>  		return NOTIFY_BAD;
>  
> +	case NETDEV_NOTIFY_PEERS:
>  	case NETDEV_RESEND_IGMP:
>  		/* Propagate to master device */
>  		call_netdevice_notifiers(event, br->dev);
> 

I'm not convinced this should be done by the bridge, setups usually have multiple ports
which may have link change events and these events are unrelated, i.e. we shouldn't generate
a gratuitous arp for all every time, there might be many different devices present. We have
setups with hundreds of ports which are mixed types of devices.
That seems inefficient, redundant and can potentially cause problems.

Also it seems this was proposed few years back: https://lkml.org/lkml/2018/1/6/135

Thanks,
 Nik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ