igb: fix race condition with PTP_TX_IN_PROGRESS bits
authorJacob Keller <jacob.e.keller@intel.com>
Wed, 3 May 2017 17:28:52 +0000 (10:28 -0700)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tue, 6 Jun 2017 07:53:07 +0000 (00:53 -0700)
commit4ccdc013b0ae04755a8f7905e0525955d52a77d0
treef8ce61d0f98eb426e2278bb2cdce7de0d1eb445c
parent5012863b7347866764c4a4e58b62fb05346b0d06
igb: fix race condition with PTP_TX_IN_PROGRESS bits

Hardware related to the igb driver has a limitation of only handling one
Tx timestamp at a time. Thus, the driver uses a state bit lock to
enforce that only one timestamp request is honored at a time.

Unfortunately this suffers from a simple race condition. The bit lock is
not cleared until after skb_tstamp_tx() is called notifying the stack of
a new Tx timestamp. Even a well behaved application which sends only one
timestamp request at once and waits for a response might wake up and
send a new packet 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
unlock.

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.

This ensures that well behaved applications do not accidentally race
with the unlock bit. Obviously an application which sends multiple Tx
timestamp requests at once will still only timestamp one packet at
a time. Unfortunately there is nothing we can do about this.

Reported-by: David Mirabito <davidm@metamako.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/igb/igb_ptp.c