* [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
@ 2020-04-30 19:38 ` Ido Schimmel
0 siblings, 0 replies; 6+ messages in thread
From: Ido Schimmel @ 2020-04-30 19:38 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, kuba, nikolay, roopa, s.priebe, mlxsw, Ido Schimmel
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)
--
2.24.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Bridge] [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
@ 2020-04-30 19:38 ` Ido Schimmel
0 siblings, 0 replies; 6+ messages in thread
From: Ido Schimmel @ 2020-04-30 19:38 UTC (permalink / raw)
To: netdev, bridge; +Cc: mlxsw, s.priebe, nikolay, roopa, Ido Schimmel, kuba, davem
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)
--
2.24.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
2020-04-30 19:38 ` [Bridge] " Ido Schimmel
@ 2020-04-30 20:25 ` Nikolay Aleksandrov
-1 siblings, 0 replies; 6+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-30 20:25 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge
Cc: davem, kuba, roopa, s.priebe, mlxsw, Ido Schimmel
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bridge] [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
@ 2020-04-30 20:25 ` Nikolay Aleksandrov
0 siblings, 0 replies; 6+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-30 20:25 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge
Cc: mlxsw, s.priebe, roopa, Ido Schimmel, kuba, davem
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
2020-04-30 19:38 ` [Bridge] " Ido Schimmel
@ 2020-05-01 0:46 ` David Miller
-1 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2020-05-01 0:46 UTC (permalink / raw)
To: idosch; +Cc: netdev, bridge, kuba, nikolay, roopa, s.priebe, mlxsw, idosch
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bridge] [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing
@ 2020-05-01 0:46 ` David Miller
0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2020-05-01 0:46 UTC (permalink / raw)
To: idosch; +Cc: mlxsw, s.priebe, nikolay, netdev, roopa, bridge, idosch, kuba
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-01 0:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-30 19:38 [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing Ido Schimmel
2020-04-30 19:38 ` [Bridge] " Ido Schimmel
2020-04-30 20:25 ` Nikolay Aleksandrov
2020-04-30 20:25 ` [Bridge] " Nikolay Aleksandrov
2020-05-01 0:46 ` David Miller
2020-05-01 0:46 ` [Bridge] " David Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.