| Message ID | 20200430193845.4087868-1-idosch@idosch.org |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net] net: bridge: vlan: Add a schedule point during VLAN processing | expand |
On 30/04/2020 22:38, Ido Schimmel wrote: > From: Ido Schimmel <idosch@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 <idosch@mellanox.com> > Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> > Tested-by: Stefan Priebe - Profihost AG <s.priebe@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 <nikolay@cumulusnetworks.com>
From: Ido Schimmel <idosch@idosch.org> Date: Thu, 30 Apr 2020 22:38:45 +0300 > From: Ido Schimmel <idosch@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 <idosch@mellanox.com> > Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> > Tested-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> Applied and queued up for -stable.
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)