[Bug 296591] Bridge(4) flaps when the first vmnet(4) interface is added

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D296591

David Horn <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected],
                   |                            |[email protected]
 Attachment #272852|                            |maintainer-approval?(ivy@Fr
              Flags|                            |eeBSD.org)

--- Comment #1 from David Horn <[email protected]> ---
Created attachment 272852
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D272852&action=
=3Dedit
Test fix to sys/net/if_bridge.c

`bridge_linkcheck()` in `sys/net/if_bridge.c` decides whether to trust memb=
er
interfaces'
real link state, or fall back to unconditionally reporting the bridge UP, b=
ased
on a single
bridge-wide flag (`hasls`, "has link state"): true if *any* current member
advertises
`IFCAP_LINKSTATE`. As long as every member lacks that capability (as is tru=
e of
`epair(4)`
and `ix(4)`/ixgbe), the bridge is always reported UP regardless of any memb=
er's
real state.
The instant the first `IFCAP_LINKSTATE`-capable member joins (`vmnet(4)`, w=
hich
=E2=80=94 like
`tap(4)` =E2=80=94 always advertises it, per `sys/net/if_tuntap.c`), that s=
afety net
disappears
for *every* member, not just the new one, and the bridge's link state becom=
es
hostage to
whatever `if_link_state` each pre-existing, previously-untracked member hap=
pens
to hold at
that exact instant. On a real box, that's exactly the moment
`bridge_ioctl_add()` also runs
`bridge_mutecaps()`, which can force a hardware NIC like `ix(4)` (iflib-bas=
ed)
through a
capability-change reinit (`iflib_stop()`/`iflib_init_locked()` in
`sys/net/iflib.c`) that
transiently reports the NIC's link down =E2=80=94 previously invisible to t=
he bridge,
now exposed
as a spurious flap.

@PHK:  Please try testing this patch and see if it helps, then we can have =
ivy@
review and see if there are any other desired changes.

--=20
You are receiving this mail because:
You are the assignee for the bug.=