On 30/04/2020 22:38, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@xxxxxxxxxxxx>
>
> 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 <idosch@xxxxxxxxxxxx>
> Reported-by: Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>
> Tested-by: Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>
> ---
> 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 <nikolay@xxxxxxxxxxxxxxxxxxx>
