qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 7/7] block/nbd: stop manipulating in_flight counter


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH 7/7] block/nbd: stop manipulating in_flight counter
Date: Tue, 16 Mar 2021 21:37:13 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

16.03.2021 19:08, Roman Kagan wrote:
On Mon, Mar 15, 2021 at 11:15:44PM +0300, Vladimir Sementsov-Ogievskiy wrote:
15.03.2021 09:06, Roman Kagan wrote:
As the reconnect logic no longer interferes with drained sections, it
appears unnecessary to explicitly manipulate the in_flight counter.

Fixes: 5ad81b4946 ("nbd: Restrict connection_co reentrance")

And here you actually allow qemu_aio_coroutine_enter() call in
nbd_client_attach_aio_context_bh() to enter connection_co in any yield
point which is possible during drained section. The analysis should be
done to be sure that all these yield points are safe for reentering by
external qemu_aio_coroutine_enter(). (By external I mean not by the
actual enter() we are waiting for at the yield() point. For example
qemu_channel_yield() supports reentering.. And therefore (as I
understand after fast looking through) nbd_read() should support
reentering too..

I'll do a more thorough analysis of how safe it is.

FWIW this hasn't triggered any test failures yet, but that assert in
patch 3 didn't ever go off either so I'm not sure I can trust the tests
on this.


Hmm. First, we should consider qemu_coroutine_yield() in 
nbd_co_establish_connection().

Most of nbd_co_establish_connection_cancel() purpose is to avoid reentering 
this yield()..

And I don't know, how to make it safely reenterable: keep in mind bh that may 
be already scheduled by connect_thread_func(). And if bh is already scheduled, 
can we cancel it? I'm not sure.

We have qemu_bh_delete(). But is it possible, that BH is near to be executed 
and already cannot be removed by qemu_bh_delete()? I don't know.

And if we can't safely drop the bh at any moment, we should wait in 
nbd_client_detach_aio_context until the scheduled bh enters the connection_co.. 
Or something like this


--
Best regards,
Vladimir



reply via email to

[Prev in Thread] Current Thread [Next in Thread]