Re: [PATCH for-5.0 v2 2/3] block: Increase BB.in_flight for coroutine interfaces

[Max Reitz]

On 07.04.20 13:13, Kevin Wolf wrote:
> Am 07.04.2020 um 12:15 hat Max Reitz geschrieben:
>> On 07.04.20 12:04, Max Reitz wrote:
>>> On 06.04.20 19:14, Kevin Wolf wrote:
>>>> External callers of blk_co_*() don't currently increase the
>>>> BlockBackend.in_flight counter, but calls from blk_aio_*() do, so there
>>>> is an inconsistency whether the counter has been increased or not.
>>>>
>>>> This patch moves the actual operations to static functions that can
>>>> later know they will always be called with in_flight increased exactly
>>>> once, even for external callers using the blk_co_*() coroutine
>>>> interfaces.
>>>>
>>>> If the public blk_co_*() interface is unused, remove it.
>>>>
>>>> Signed-off-by: Kevin Wolf <address@hidden>
>>>> ---
>>>>  include/sysemu/block-backend.h |  1 -
>>>>  block/block-backend.c          | 94 +++++++++++++++++++++++++++-------
>>>>  2 files changed, 76 insertions(+), 19 deletions(-)
>>>
>>> Reviewed-by: Max Reitz <address@hidden>
>>
>> On second thought (I assumed this would be addressed by the third
>> patch), blk_prw() no longer increments in_flight, but the blk_co_*
>> functions do that now.  In v1, blk_prw() did that.
>>
>> I thought we’d want blk_prw() to set in_flight, just like blk_aio_prwv()
>> does, and then let the synchronous functions that use blk_prw() pass the
>> blk_do_* functions to it.
> 
> Does it make a difference, though?

You mean because blk_prw() has a fast path for “already in coroutine”?
Perhaps not.  Still, feels a bit weird to me not to have in_flight
incremented around a potential POLL loop.

Maybe mostly I was wondering why v1 did and v2 didn’t. *shrug*

Max

> But the change should be easy enough (inc/dec in blk_prw() and the let
> *_entry() call blk_do_*() instead of blk_co_*()) that I guess I can just
> do it and send a v3.
> 
> Kevin
>

signature.asc
Description: OpenPGP digital signature