qemu-block
[Top][All Lists]
Advanced

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

Re: What is bs->reqs_lock for?


From: Vladimir Sementsov-Ogievskiy
Subject: Re: What is bs->reqs_lock for?
Date: Thu, 13 Aug 2020 19:34:28 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

13.08.2020 18:54, Paolo Bonzini wrote:
On 13/08/20 16:57, Vladimir Sementsov-Ogievskiy wrote:
Hi!

Sorry my stupid question, but which kind of concurrent access
bs->reqs_lock prevents?

In my understanding the whole logic of request tracking for the bs is
going in the coroutine, so, we don't have parallel access anyway? How
can parallel access to bs->tracked_requests happen?

Different iothreads can access the same BlockDriverState, and block/io.c
is not protected by the AioContext lock (in fact almost nothing, or
nothing, needs it in the I/O path).


I thought bs is attached to one aio context and aio context attached to one 
iothread.
And all normal request processing of the bs is done in this one iothread.
And when we need to access bs externally, we do it in
aio_context_acquire / aio_context_release, which protects from parallel access 
to
BlockDriverState fields...

But you say, that block/io.c is not protected by AioContext lock..

Does it mean that everything must be thread-safe in block/io.c and all block 
drivers?

Are tracked_requests different from other fields? A lot of other 
BlockDriverState
fields are not protected by any mutex.. For example: total_sectors, file, 
backing..

Could you give an example of parallel access to tracked_requests?

--
Best regards,
Vladimir



reply via email to

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