On 30/04/2020 22:38, Ido Schimmel wrote:
> From: Ido Schimmel <ido...@mellanox.com>
> 
> User space can request to delete a range of VLANs from a bridge slave in
> one netlink request. For each deleted VLAN the FDB needs to be traversed
> in order to flush all the affected entries.
> 
> If a large range of VLANs is deleted and the number of FDB entries is
> large or the FDB lock is contented, it is possible for the kernel to
> loop through the deleted VLANs for a long time. In case preemption is
> disabled, this can result in a soft lockup.
> 
> Fix this by adding a schedule point after each VLAN is deleted to yield
> the CPU, if needed. This is safe because the VLANs are traversed in
> process context.
> 
> Fixes: bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in 
> setlink and dellink requests")
> Signed-off-by: Ido Schimmel <ido...@mellanox.com>
> Reported-by: Stefan Priebe - Profihost AG <s.pri...@profihost.ag>
> Tested-by: Stefan Priebe - Profihost AG <s.pri...@profihost.ag>
> ---
>  net/bridge/br_netlink.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index 43dab4066f91..a0f5dbee8f9c 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -612,6 +612,7 @@ int br_process_vlan_info(struct net_bridge *br,
>                                              v - 1, rtm_cmd);
>                               v_change_start = 0;
>                       }
> +                     cond_resched();
>               }
>               /* v_change_start is set only if the last/whole range changed */
>               if (v_change_start)
> 

Looks good, thanks!
Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Reply via email to