Skip to content

net: gptp: release stranded Sync on port reset - #117400

Open
bperseghetti wants to merge 1 commit into
zephyrproject-rtos:mainfrom
CogniPilot:pr-deps-gptp-sync-release
Open

net: gptp: release stranded Sync on port reset#117400
bperseghetti wants to merge 1 commit into
zephyrproject-rtos:mainfrom
CogniPilot:pr-deps-gptp-sync-release

Conversation

@bperseghetti

@bperseghetti bperseghetti commented Aug 26, 2026

Copy link
Copy Markdown
Member

When the Sync send state machine resets while a Sync is waiting for its transmit timestamp, that Sync will never be given one and the port that was to produce it is down or no longer capable. The reset path left the packet reference held and the timestamp callback registered, so the packet and its buffers leaked from the pool for good and no later Sync could ever register a callback, leaving the machine unable to transmit timestamped Syncs after recovery.

Release the stranded Sync and reset the callback registration in the reset path. Independently valid for any driver whose port drops mid-Sync.

Validated on NXP MCXN947 hardware acting as a time transmitter across repeated physical link flaps. Sync transmission resumes after every flap and the TX buffer pool shows no per-flap leak.

A Sync waiting for its transmit timestamp is stranded when the port that
was to produce it goes down or stops being capable: the sync send state
machine is left in SEND_FUP waiting for a timestamp that never comes. The
reset path returns without releasing the held Sync or its registered
timestamp callback, so the packet reference is dropped on the floor at
the next SEND_SYNC, which loses a packet and its buffers from the pool
for good, and the stale callback keeps pointing at a packet that is never
transmitted again, leaving no later Sync timestamped.

Release the pending Sync and unregister its timestamp callback through
the new gptp_sync_send_reset() so the next Sync registers a callback of
its own.

Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a gPTP Sync-send recovery failure when a port drops while a Sync is pending a TX timestamp. Previously, the Sync send state machine reset path could leave a referenced sync_ptr and a registered timestamp callback behind, leaking packet buffers and preventing subsequent Syncs from registering a callback after the port recovered.

Changes:

  • Add gptp_sync_send_reset() helper to explicitly unregister the per-port Sync TX timestamp callback.
  • On Sync send state machine reset due to port disabled / not as_capable, release any stranded sync_ptr, unregister the timestamp callback, and clear related state flags.
  • Expose the helper in gptp_messages.h with Doxygen documentation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File Description
subsys/net/l2/ethernet/gptp/gptp_messages.h Declares gptp_sync_send_reset() with API documentation for resetting a stranded Sync timestamp callback.
subsys/net/l2/ethernet/gptp/gptp_messages.c Implements gptp_sync_send_reset() to unregister the Sync timestamp callback and clear the registration flag.
subsys/net/l2/ethernet/gptp/gptp_md.c Updates Sync send state machine reset path to unref a stranded Sync and reset callback/flags when the port is down or not capable.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants