When a vxlan device has vnifilter enabled, userspace observers
(e.g., bridge monitor vni) miss VNI add events and see spurious
notifications on no-op VNI re-adds.
Patch 1 fixes the missing notification on VNI add: vxlan_vni_add()
guarded the notification on a 'changed' flag that vxlan_vni_update_group()
only sets when a multicast group or remote is supplied, so VNIs added
without a group (e.g., L3 VXLAN) were silently created.
Patch 2 fixes the spurious notification on VNI update: vxlan_vni_update()
tested 'if (changed)' against a bool pointer instead of dereferencing it,
so every re-add produced a notification regardless of whether anything
actually changed.
Patch 3 adds a selftest covering both bugs along with a few related
cases (add with remote, remote update, delete-nonexistent).
Changes since v1:
- Retarget to net.
- Patch 3: improved vni_notify_check helper based on review by
sashiko.dev:
* Bump pre-cmd sleep 0.1s -> 0.5s.
* Add /proc/$monitor_pid liveness check and ksft_skip if
iproute2 doesn't support 'bridge monitor vni'.
* Capture and propagate "$@"'s exit status so check_err $?
actually validates the bridge command's return.
v1: https://lore.kernel.org/netdev/[email protected]/
Andy Roulin (3):
vxlan: vnifilter: send notification on VNI add
vxlan: vnifilter: fix spurious notification on VNI update
selftests: net: add vxlan vnifilter notification test
drivers/net/vxlan/vxlan_vnifilter.c | 5 +-
tools/testing/selftests/net/Makefile | 1 +
.../net/test_vxlan_vnifilter_notify.sh | 184 ++++++++++++++++++
3 files changed, 187 insertions(+), 3 deletions(-)
create mode 100755 tools/testing/selftests/net/test_vxlan_vnifilter_notify.sh
--
2.43.0
