| Message ID | 42c317f8cfd35becd2a160c400cf4834d53bcef6.1552056324.git.sbrivio@redhat.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net] vxlan: Fix GRO cells race condition between receive and link delete | expand |
On 03/08/2019 07:40 AM, Stefano Brivio wrote: > If we receive a packet while deleting a VXLAN device, there's a chance > vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, > except that vxlan_dellink() should never ever touch stuff that's still in > use, such as the GRO cells list. > > Otherwise, vxlan_rcv() crashes while queueing packets via > gro_cells_receive(). > > Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU > grace period is elapsed and nothing needs the gro_cells anymore. > > This is now done in the same way as commit 8e816df87997 ("geneve: Use GRO > cells infrastructure.") originally implemented for GENEVE. > > Reported-by: Jianlin Shi <jishi@redhat.com> > Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") > Signed-off-by: Stefano Brivio <sbrivio@redhat.com> > Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Nice catch, thanks. Reviewed-by: Eric Dumazet <edumazet@google.com>
From: Stefano Brivio <sbrivio@redhat.com> Date: Fri, 8 Mar 2019 16:40:57 +0100 > If we receive a packet while deleting a VXLAN device, there's a chance > vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, > except that vxlan_dellink() should never ever touch stuff that's still in > use, such as the GRO cells list. > > Otherwise, vxlan_rcv() crashes while queueing packets via > gro_cells_receive(). > > Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU > grace period is elapsed and nothing needs the gro_cells anymore. > > This is now done in the same way as commit 8e816df87997 ("geneve: Use GRO > cells infrastructure.") originally implemented for GENEVE. > > Reported-by: Jianlin Shi <jishi@redhat.com> > Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") > Signed-off-by: Stefano Brivio <sbrivio@redhat.com> > Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Applied and queued up for -stable, thank you.
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index a3c46d78d216..76abd31e8d56 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2767,6 +2767,8 @@ static void vxlan_uninit(struct net_device *dev) { struct vxlan_dev *vxlan = netdev_priv(dev); + gro_cells_destroy(&vxlan->gro_cells); + vxlan_fdb_delete_default(vxlan, vxlan->cfg.vni); free_percpu(dev->tstats); @@ -3942,7 +3944,6 @@ static void vxlan_dellink(struct net_device *dev, struct list_head *head) vxlan_flush(vxlan, true); - gro_cells_destroy(&vxlan->gro_cells); list_del(&vxlan->next); unregister_netdevice_queue(dev, head); }
If we receive a packet while deleting a VXLAN device, there's a chance vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, except that vxlan_dellink() should never ever touch stuff that's still in use, such as the GRO cells list. Otherwise, vxlan_rcv() crashes while queueing packets via gro_cells_receive(). Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU grace period is elapsed and nothing needs the gro_cells anymore. This is now done in the same way as commit 8e816df87997 ("geneve: Use GRO cells infrastructure.") originally implemented for GENEVE. Reported-by: Jianlin Shi <jishi@redhat.com> Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> --- drivers/net/vxlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)