From: Emanuele Giuseppe Esposito <eesposit@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
John Snow <jsnow@redhat.com>, Eric Blake <eblake@redhat.com>,
Fam Zheng <fam@euphon.net>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2 2/9] block-copy: add missing coroutine_fn annotations
Date: Tue, 8 Nov 2022 16:09:54 +0100 [thread overview]
Message-ID: <88f02d19-84d8-d1a7-4250-416fd32f1435@redhat.com> (raw)
In-Reply-To: <197f2a27-4c3f-a62b-535c-d1db9ba22a32@yandex-team.ru>
Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
>> These functions end up calling bdrv_common_block_status_above(), a
>> generated_co_wrapper function.
>
> generated_co_wrapper is not a coroutine_fn. Сonversely it's a function
> that do a class coroutine wrapping - start a coroutine and do POLL to
> wait for the coroutine to finish.
>
>> In addition, they also happen to be always called in coroutine context,
>> meaning all callers are coroutine_fn.
>
> That's also not a reason for marking them coroutine_fn. "coroutine_fn"
> means that the function can be called only from coroutine context.
>
>> This means that the g_c_w function will enter the qemu_in_coroutine()
>> case and eventually suspend (or in other words call
>> qemu_coroutine_yield()).
>> Therefore we need to mark such functions coroutine_fn too.
>
> I don't think so. Moreover, this breaks the concept, as your new
> coroutine_fn functions will call generated_co_wrapper functions which
> are not marked coroutine_fn and never was.
Theoretically not, because marking it coroutine_fn we know that we are
going in the if(qemu_in_coroutine()) branch of the g_c_w, so we could
directly replace it with the actual function. Because it's a pain to do
it with hand, and at some point I/someone should use Alberto static
analyzer to get rid of that, I decided to leave g_c_w there.
As I understand it, it seems that you and Paolo have a different
understanding on what coroutine_fn means and where it should be used.
Honestly I don't understand your point, as you said
> "coroutine_fn"
> means that the function can be called only from coroutine context.
which is the case for these functions. So could you please clarify?
What I do know is that it's extremely confusing to understand if a
function that is *not* marked as coroutine_fn is actually being called
also from coroutines or not.
Which complicates A LOT whatever change or operation I want to perform
on the BlockDriver callbacks or any other function in the block layer,
because in the current approach for the AioContext lock removal (which
you are not aware of, I understand) we need to distinguish between
functions running in coroutine context and not, and throwing g_c_w
functions everywhere makes my work much harder that it already is.
Thank you,
Emanuele
>
>>
>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>> ---
>> block/block-copy.c | 15 +++++++++------
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/block/block-copy.c b/block/block-copy.c
>> index bb947afdda..f33ab1d0b6 100644
>> --- a/block/block-copy.c
>> +++ b/block/block-copy.c
>> @@ -577,8 +577,9 @@ static coroutine_fn int
>> block_copy_task_entry(AioTask *task)
>> return ret;
>> }
>> -static int block_copy_block_status(BlockCopyState *s, int64_t offset,
>> - int64_t bytes, int64_t *pnum)
>> +static coroutine_fn int block_copy_block_status(BlockCopyState *s,
>> + int64_t offset,
>> + int64_t bytes,
>> int64_t *pnum)
>> {
>> int64_t num;
>> BlockDriverState *base;
>> @@ -613,8 +614,9 @@ static int block_copy_block_status(BlockCopyState
>> *s, int64_t offset,
>> * Check if the cluster starting at offset is allocated or not.
>> * return via pnum the number of contiguous clusters sharing this
>> allocation.
>> */
>> -static int block_copy_is_cluster_allocated(BlockCopyState *s, int64_t
>> offset,
>> - int64_t *pnum)
>> +static int coroutine_fn
>> block_copy_is_cluster_allocated(BlockCopyState *s,
>> + int64_t offset,
>> + int64_t *pnum)
>> {
>> BlockDriverState *bs = s->source->bs;
>> int64_t count, total_count = 0;
>> @@ -669,8 +671,9 @@ void block_copy_reset(BlockCopyState *s, int64_t
>> offset, int64_t bytes)
>> * @return 0 when the cluster at @offset was unallocated,
>> * 1 otherwise, and -ret on error.
>> */
>> -int64_t block_copy_reset_unallocated(BlockCopyState *s,
>> - int64_t offset, int64_t *count)
>> +int64_t coroutine_fn block_copy_reset_unallocated(BlockCopyState *s,
>> + int64_t offset,
>> + int64_t *count)
>> {
>> int ret;
>> int64_t clusters, bytes;
>
next prev parent reply other threads:[~2022-11-08 15:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 9:56 [PATCH v2 0/9] Still more coroutine and various fixes in block layer Emanuele Giuseppe Esposito
2022-11-04 9:56 ` [PATCH v2 1/9] block: call bdrv_co_drain_begin in a coroutine Emanuele Giuseppe Esposito
2022-11-08 14:33 ` Vladimir Sementsov-Ogievskiy
2022-11-08 15:13 ` Emanuele Giuseppe Esposito
2022-11-08 15:52 ` Vladimir Sementsov-Ogievskiy
2022-11-08 16:06 ` Emanuele Giuseppe Esposito
2022-11-08 15:20 ` Kevin Wolf
2022-11-04 9:56 ` [PATCH v2 2/9] block-copy: add missing coroutine_fn annotations Emanuele Giuseppe Esposito
2022-11-08 14:48 ` Vladimir Sementsov-Ogievskiy
2022-11-08 15:09 ` Emanuele Giuseppe Esposito [this message]
2022-11-08 16:19 ` Vladimir Sementsov-Ogievskiy
2022-11-08 16:30 ` Vladimir Sementsov-Ogievskiy
2022-11-09 12:23 ` Emanuele Giuseppe Esposito
2022-11-09 23:52 ` Alberto Faria
2022-11-10 10:52 ` Paolo Bonzini
2022-11-15 15:41 ` Emanuele Giuseppe Esposito
2022-11-16 16:40 ` Paolo Bonzini
2022-11-04 9:56 ` [PATCH v2 3/9] nbd/server.c: " Emanuele Giuseppe Esposito
2022-11-08 14:54 ` Vladimir Sementsov-Ogievskiy
2022-11-04 9:56 ` [PATCH v2 4/9] block-backend: replace bdrv_*_above with blk_*_above Emanuele Giuseppe Esposito
2022-11-04 9:56 ` [PATCH v2 5/9] block: distinguish between bdrv_create running in coroutine and not Emanuele Giuseppe Esposito
2022-11-08 14:59 ` Vladimir Sementsov-Ogievskiy
2022-11-04 9:56 ` [PATCH v2 6/9] block/vmdk: add missing coroutine_fn annotations Emanuele Giuseppe Esposito
2022-11-04 9:56 ` [PATCH v2 7/9] block: bdrv_create_file is a coroutine_fn Emanuele Giuseppe Esposito
2022-11-04 9:56 ` [PATCH v2 8/9] block: bdrv_create is never called in non-coroutine context Emanuele Giuseppe Esposito
2022-11-08 15:23 ` Kevin Wolf
2022-11-04 9:57 ` [PATCH v2 9/9] block/dirty-bitmap: remove unnecessary qemu_in_coroutine() case Emanuele Giuseppe Esposito
2022-11-04 13:16 ` [PATCH v2 0/9] Still more coroutine and various fixes in block layer Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88f02d19-84d8-d1a7-4250-416fd32f1435@redhat.com \
--to=eesposit@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).