Hi, 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. Thanks, Nik Nikolay Aleksandrov (7): net: bridge: fdb: convert is_local to bitops net: bridge: fdb: convert is_static to bitops net: bridge: fdb: convert is_sticky to bitops net: bridge: fdb: convert added_by_user to bitops net: bridge: fdb: convert added_by_external_learn to use bitops net: bridge: fdb: convert offloaded to use bitops net: bridge: fdb: set flags directly in fdb_create net/bridge/br_fdb.c | 133 +++++++++++++++++++------------------- net/bridge/br_input.c | 2 +- net/bridge/br_private.h | 17 +++-- net/bridge/br_switchdev.c | 12 ++-- 4 files changed, 85 insertions(+), 79 deletions(-) -- 2.21.0
