bridge tests: Test for #216510
ClosedPublic
Actions

Authored by kp on Apr 1 2020, 2:26 PM.

Details

Reviewers

emaste
philip

Group Reviewers

network

Commits

rG1b73cd3d0a7c: bridge tests: Test for #216510
rS360346: bridge tests: Test for #216510

Summary

We used to have an issue with recursive locking with
net.link.bridge.inherit_mac. This causes us to send an ARP request while
we hold the BRIDGE_LOCK, which used to cause us to acquire the
BRIDGE_LOCK again. We can't re-acquire it, so this caused a panic.

Now that we no longer need to acquire the BRIDGE_LOCK for
bridge_transmit() this should no longer panic. Test this.

PR: 216510
Sponsored by: The FreeBSD Foundation

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

kp created this revision.Apr 1 2020, 2:26 PM

Herald added subscribers: melifaro, ae. · View Herald TranscriptApr 1 2020, 2:26 PM

Harbormaster completed remote builds in B30230: Diff 70092.Apr 1 2020, 2:26 PM

kp added a parent revision: D24250: bridge: epoch-ification.Apr 1 2020, 2:27 PM

LGTM

tests/sys/net/if_bridge_test.sh
251 ↗	(On Diff #70092)	Is this a standard way we reference PRs in tests? I'd probably expect PR216510

This revision is now accepted and ready to land.Apr 1 2020, 2:42 PM

Thanks for the review. This can't be committed until the lock rework of the bridge is pushed, because without it this will trigger a recursive lock of BRIDGE_LOCK and panic.

tests/sys/net/if_bridge_test.sh
251 ↗	(On Diff #70092)	I don't know if we have a standard way of doing this. There are a couple more that use #12345, but those are mostly mine. There's also a few 'PR 123456' and at least one 'PR kern/123456'.