On Tue, Apr 26, 2022 at 04:51:07AM -0400, Emanuele Giuseppe Esposito wrote:
> It seems that aio_wait_kick always required a memory barrier
> or atomic operation in the caller, but almost nobody actually
> took care of doing it.
>
> Let's put the barrier in the function instead.
>
> Signed-off-by: Emanuele Giuseppe Esposito <eespo...@redhat.com>
> ---
> util/aio-wait.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/util/aio-wait.c b/util/aio-wait.c
> index bdb3d3af22..c0a343ac87 100644
> --- a/util/aio-wait.c
> +++ b/util/aio-wait.c
> @@ -35,7 +35,8 @@ static void dummy_bh_cb(void *opaque)
>
> void aio_wait_kick(void)
> {
> - /* The barrier (or an atomic op) is in the caller. */
> + smp_mb();
What is the purpose of the barrier and what does it pair with?
I guess we want to make sure that all stores before aio_wait_kick() are
visible to the other thread's AIO_WAIT_WHILE() cond expression. that
would require smp_wmb(). I'm not sure why it's a full smp_mb() barrier.
> +
> if (qatomic_read(&global_aio_wait.num_waiters)) {
> aio_bh_schedule_oneshot(qemu_get_aio_context(), dummy_bh_cb, NULL);
> }
> --
> 2.31.1
>
signature.asc
Description: PGP signature
