The following is an issue identified by AI when I asked it to do an adversarial code review of #795. This was pre-existing in the sync/pthread impl, which is why it was not addressed as part of the async swap-out.
Problem
BFD configuration permits required_rx = 0.
The state machine currently computes its receive timeout approximately
as:
local.required_min_rx * local.detection_multiplier
When required_rx is zero, every receive deadline equals the current
instant. The session driver repeatedly:
- observes an immediately expired timeout;
- re-arms another immediate timeout;
- increments the timeout counter;
- loops again.
The synchronous implementation had the same basic timer defect, but it
consumed a dedicated BFD thread. The async implementation runs this loop
on mgd's shared Tokio runtime, increasing the impact on unrelated BFD
sessions and API work.
Impact
One configuration can cause persistent CPU consumption and scheduler
pressure. Multiple such sessions may affect unrelated work running on
the Tokio runtime.
Protocol consideration
RFC 5880 gives Required Min RX Interval zero a meaning: the system does
not want to receive periodic BFD Control packets. It does not mean that
the receive deadline should continually expire.
Correct detection-time calculation also depends on the remote Desired
Min TX interval, so fixing timer negotiation may naturally eliminate
the zero deadline.
Proposed direction
This should be coordinated with #798.
Possible approaches:
- represent a disabled periodic receive expectation explicitly; or
- calculate the detection deadline from the negotiated interval rather
than local Required Min RX alone; or
- reject zero at the management boundary if Maghemite intentionally
chooses not to support its RFC meaning.
The driver should also avoid repeatedly expiring a receive timer while
the session is already Down.
Testing
Add a current-thread Tokio test containing:
- a session configured with
required_rx = 0; and
- an independent heartbeat task.
Verify that the heartbeat continues to run and the BFD driver does not
produce an unbounded stream of expiration events.
Also test zero in combination with a nonzero remote Desired Min TX
interval after timer negotiation is implemented.
Related issues
The following is an issue identified by AI when I asked it to do an adversarial code review of #795. This was pre-existing in the sync/pthread impl, which is why it was not addressed as part of the async swap-out.
Problem
BFD configuration permits
required_rx = 0.The state machine currently computes its receive timeout approximately
as:
When
required_rxis zero, every receive deadline equals the currentinstant. The session driver repeatedly:
The synchronous implementation had the same basic timer defect, but it
consumed a dedicated BFD thread. The async implementation runs this loop
on mgd's shared Tokio runtime, increasing the impact on unrelated BFD
sessions and API work.
Impact
One configuration can cause persistent CPU consumption and scheduler
pressure. Multiple such sessions may affect unrelated work running on
the Tokio runtime.
Protocol consideration
RFC 5880 gives Required Min RX Interval zero a meaning: the system does
not want to receive periodic BFD Control packets. It does not mean that
the receive deadline should continually expire.
Correct detection-time calculation also depends on the remote Desired
Min TX interval, so fixing timer negotiation may naturally eliminate
the zero deadline.
Proposed direction
This should be coordinated with #798.
Possible approaches:
than local Required Min RX alone; or
chooses not to support its RFC meaning.
The driver should also avoid repeatedly expiring a receive timer while
the session is already Down.
Testing
Add a current-thread Tokio test containing:
required_rx = 0; andVerify that the heartbeat continues to run and the BFD driver does not
produce an unbounded stream of expiration events.
Also test zero in combination with a nonzero remote Desired Min TX
interval after timer negotiation is implemented.
Related issues