On 4/12/21 5:20 PM, Gaetan Rivet wrote:
> When a thread is blocked on a barrier, there is no guarantee
> regarding the moment it will resume, only that it will at some point in
> the future.
>
> One thread can resume first then proceed to destroy the barrier while
> another thread has not yet awoken. When it finally happens, the second
> thread will attempt a seq_read() on the barrier seq, while the first
> thread have already destroyed it, triggering a use-after-free.
>
> Introduce an additional indirection layer within the barrier.
> A internal barrier implementation holds all the necessary elements
> for a thread to safely block and destroy. Whenever a barrier is
> destroyed, the internal implementation is left available to still
> blocking threads if necessary. A reference counter is used to track
> threads still using the implementation.
>
> Note that current uses of ovs-barrier are not affected: RCU and
> revalidators will not destroy their barrier immediately after blocking
> on it.
>
> Fixes: d8043da7182a ("ovs-thread: Implement OVS specific barrier.")
> Signed-off-by: Gaetan Rivet <[email protected]>
> ---
> lib/ovs-thread.c | 61 +++++++++++++++++++++++++++++++++++++++---------
> lib/ovs-thread.h | 6 ++---
> 2 files changed, 53 insertions(+), 14 deletions(-)
Reviewed-by: Maxime Coquelin <[email protected]>
Thanks,
Maxime
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
