[RFC 15/32] event/sw: fix unlinks in progress counter races

Bruce Richardson bruce.richardson at intel.com
Thu Aug 13 12:38:57 CEST 2026


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: stable at dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>


More information about the stable mailing list