Page MenuHomeFreeBSD

netgraph/ng_bridge: Document staleness in multithreaded operation
ClosedPublic

Authored by donner on Mon, Feb 8, 10:10 PM.

Details

Summary

In the data path of ng_bridge(4), the only value of an host struct,
which needs to be modified, is the staleness, which is reset every
time a frame was received. It's save to leave the code as it is.

Depends on D28545

Test Plan

No functional changes.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

I don't know if counter(9) makes sense here. That's usually intended for statistical information (e.g. how many packets passed through this interface). This looks like something that wants to be protected by a lock, or implemented with an atomic.

In D28546#639111, @kp wrote:

I don't know if counter(9) makes sense here.

The only shared access to the variable is setting it to zero.
All other operations (like regular callouts and control message processing) already have a WRITER lock on the whole node.

So there is no need for any synchronization all.
The only change to make is to document this reasoning.

  • Revert "Switch staleness to counter framework."
  • Comment why it's safe to do so.
donner retitled this revision from netgraph/ng_bridge: Switch staleness to counter framework to netgraph/ng_bridge: Document staleness in multithreaded operation.Tue, Feb 9, 11:35 AM
donner edited the summary of this revision. (Show Details)

OTOH it's bad, because it prevents the code from running under const constraints.

This revision is now accepted and ready to land.Tue, Feb 9, 1:43 PM