summaryrefslogtreecommitdiff
path: root/drivers/nfc
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2019-10-29 18:12:49 -0700
committerDavid S. Miller <davem@davemloft.net>2019-10-29 18:12:49 -0700
commit9014fc319b4b5c092e02fedabcf7d4c1266e0c4a (patch)
tree1593f1bd99efccfd38ae3530fa5eaad9909ed9e9 /drivers/nfc
parent8466a57dfbb0c9bf6db4685ed9c4144b8deec688 (diff)
parent3fb01a31afdab9f046fc11ce430c69e6e3b7b9a6 (diff)
downloadlwn-9014fc319b4b5c092e02fedabcf7d4c1266e0c4a.tar.gz
lwn-9014fc319b4b5c092e02fedabcf7d4c1266e0c4a.zip
Merge branch 'bridge-fdbs-bitops'
Nikolay Aleksandrov says: ==================== net: bridge: convert fdbs to use bitops We'd like to have a well-defined behaviour when changing fdb flags. The problem is that we've added new fields which are changed from all contexts without any locking. We are aware of the bit test/change races and these are fine (we can remove them later), but it is considered undefined behaviour to change bitfields from multiple threads and also on some architectures that can result in unexpected results, specifically when all fields between the changed ones are also bitfields. The conversion to bitops shows the intent clearly and makes them use functions with well-defined behaviour in such cases. There is no overhead for the fast-path, the bit changing functions are used only in special cases when learning and in the slow path. In addition this conversion allows us to simplify fdb flag handling and avoid bugs for future bits (e.g. a forgetting to clear the new bit when allocating a new fdb). All bridge selftests passed, also tried all of the converted bits manually in a VM. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/nfc')
0 files changed, 0 insertions, 0 deletions