diff options
author | David S. Miller <davem@davemloft.net> | 2019-10-29 18:12:49 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-10-29 18:12:49 -0700 |
commit | 9014fc319b4b5c092e02fedabcf7d4c1266e0c4a (patch) | |
tree | 1593f1bd99efccfd38ae3530fa5eaad9909ed9e9 /drivers/nfc/pn533 | |
parent | 8466a57dfbb0c9bf6db4685ed9c4144b8deec688 (diff) | |
parent | 3fb01a31afdab9f046fc11ce430c69e6e3b7b9a6 (diff) | |
download | linux-stable-9014fc319b4b5c092e02fedabcf7d4c1266e0c4a.tar.gz linux-stable-9014fc319b4b5c092e02fedabcf7d4c1266e0c4a.tar.bz2 linux-stable-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/pn533')
0 files changed, 0 insertions, 0 deletions