On Wed, Jul 29, 2026 at 10:54:08AM -0700, Stephen Hemminger wrote:
> The counter is written by both the application thread (increment on
> unlink) and the scheduler (clear on ack) as a plain uint8_t. An
> increment is lost if it lands between the scheduler's test and clear,
> making rte_event_port_unlinks_in_progress() report completion before
> the scheduler has seen the unlink. Nothing orders the scheduler's
> later cq map reads against the counter test on a weakly ordered CPU
> either.
> 
> Make the counter atomic: release fetch-add on unlink, acquire
> exchange to clear. The exchange cannot lose a concurrent increment,
> and the acquire guarantees the scheduler only acks unlinks whose cq
> map update it can observe, replacing the full barrier in unlink.
> 
> Fixes: bd5ac24fea88 ("event/sw: implement unlinks in progress function")
> Cc: [email protected]
> 
> Signed-off-by: Stephen Hemminger <[email protected]>
Acked-by: Bruce Richardson <[email protected]>

Reply via email to