summaryrefslogtreecommitdiffstats
path: root/fs/utimes.c
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2017-10-27 11:06:52 -0400
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2018-01-10 12:41:21 -0800
commit9b2aef128bff371c1b91b492a92cf42dad8c739b (patch)
tree4e134cb79b6978eeb02f039d93e5b723e2a51a56 /fs/utimes.c
parent22ab4086579b342752bcb11d38d627bf6b38690c (diff)
downloadlinux-9b2aef128bff371c1b91b492a92cf42dad8c739b.tar.bz2
i40evf: hold the critical task bit lock while opening
If i40evf_open() is called quickly at the same time as a reset occurs (such as via ethtool) it is possible for the device to attempt to open while a reset is in progress. This occurs because the driver was not holding the critical task bit lock during i40evf_open, nor was it holding it around the call to i40evf_up_complete() in i40evf_reset_task(). We didn't hold the lock previously because calls to i40evf_down() would take the bit lock directly, and this would have caused a deadlock. To avoid this, we'll move the bit lock handling out of i40evf_down() and into the callers of this function. Additionally, we'll now hold the bit lock over the entire set of steps when going up or down, to ensure that we remain consistent. Ultimately this causes us to serialize the transitions between down and up properly, and avoid changing status while we're resetting. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'fs/utimes.c')
0 files changed, 0 insertions, 0 deletions