i40e: Fix multiple issues with UDP tunnel offload filter configuration
authorAlexander Duyck <alexander.h.duyck@intel.com>
Fri, 20 Apr 2018 08:41:37 +0000 (01:41 -0700)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Mon, 30 Apr 2018 16:21:42 +0000 (09:21 -0700)
commit5305d0fe2f22ec42b19f5ed205faad9b26955e5c
treebdeaafa9446f2cdf6dc9a204b5c07dd0993f2c7f
parente4062894d5939bbba9fbed5a70a9eaf6fa397b10
i40e: Fix multiple issues with UDP tunnel offload filter configuration

This fixes at least 2 issues I have found with the UDP tunnel filter
configuration.

The first issue is the fact that the tunnels didn't have any sort of mutual
exclusion in place to prevent an update from racing with a user request to
add/remove a port. As such you could request to add and remove a port
before the port update code had a chance to respond which would result in a
very confusing result. To address it I have added 2 changes. First I added
the RTNL mutex wrapper around our updating of the pending, port, and
filter_index bits. Second I added logic so that we cannot use a port that
has a pending deletion since we need to free the space in hardware before
we can allow software to reuse it.

The second issue addressed is the fact that we were not recording the
actual filter index provided to us by the admin queue. As a result we were
deleting filters that were not associated with the actual filter we wanted
to delete. To fix that I added a filter_index member to the UDP port
tracking structure.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/i40e/i40e.h
drivers/net/ethernet/intel/i40e/i40e_main.c