i40e: fix race condition with PTP_TX_IN_PROGRESS bits
authorJacob Keller <jacob.e.keller@intel.com>
Wed, 3 May 2017 17:28:51 +0000 (10:28 -0700)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Wed, 31 May 2017 10:03:33 +0000 (03:03 -0700)
commitbbc4e7d273b594debbcccdf588085b3521365c50
treefef7f84babd045810b8e60e303927fd8e95096d6
parent9d68322e53e683e332c032def9854501f9cbf4e8
i40e: fix race condition with PTP_TX_IN_PROGRESS bits

Hardware related to the i40e driver has a limitation on Tx PTP packets.
This requires us to limit the driver to timestamping a single packet at
once. This is done using a state bitlock which enforces that only one
timestamp request is honored at a time.

Unfortunately this suffers from a race condition. The bit lock is not
cleared until after skb_tstamp_tx() is called notifying applications of
a new Tx timestamp. Even a well behaved application sending only one
packet at a time and waiting for a response can wake up and send a new
timestamped packet request before the bit lock is cleared. This results
in needlessly dropping some Tx timestamp requests.

We can fix this by unlocking the state bit as soon as we read the
Timestamp register, as this is the first point at which it is safe to
timestamp another packet.

To avoid issues with the skb pointer, we'll use a copy of the pointer
and set the global variable in the driver structure to NULL first. This
ensures that the next timestamp request does not modify our local copy
of the skb pointer.

Now, a well behaved application which has at most one outstanding
timestamp request will not accidentally race with the driver unlock bit.
Obviously an application attempting to timestamp faster than one request
at a time will have some timestamp requests skipped. Unfortunately there
is nothing we can do about that.

Reported-by: David Mirabito <davidm@metamako.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/i40e/i40e_ptp.c