summaryrefslogtreecommitdiff
path: root/kernel/events/Makefile
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2017-06-23 11:24:50 +0300
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2017-08-26 00:46:34 +0300
commit841c950d67c6facde32a8644ced20c04aebb7dd8 (patch)
tree40940c57be54a3058491e582cb0cad345c8ac562 /kernel/events/Makefile
parent10a955ff62e56fe13dae1f29aabc04bc589eaf46 (diff)
downloadlinux-841c950d67c6facde32a8644ced20c04aebb7dd8.tar.xz
i40e/i40evf: use cmpxchg64 when updating private flags in ethtool
When a user gives an invalid command to change a private flag which is not supported, either because it is read-only, or the device is not capable of the feature, we simply ignore the request. A naive solution would simply be to report error codes when one of the flags was not supported. However, this causes problems because it makes the operation not atomic. If a user requests multiple private flags together at once we could end up changing one before failing at the second flag. We can do a bit better if we instead update a temporary copy of the flags variable in the loop, and then copy it into place after. If we aren't careful this has the pitfall of potentially silently overwriting any changes caused by other threads. Avoid this by using cmpxchg64 which will compare and swap the flags variable only if it currently matched the old value. We'll report -EAGAIN in the (hopefully rare!) case where the cmpxchg64 fails. This ensures that we can properly report when flags are not supported in an atomic fashion without the risk of overwriting other threads changes. 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 'kernel/events/Makefile')
0 files changed, 0 insertions, 0 deletions