From: John Snow <jsnow@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] dma-helpers: ensure AIO callback is invoked after cancellation
Date: Mon, 29 Jul 2019 18:00:23 -0400 [thread overview]
Message-ID: <8b7da43c-bf05-eef1-407d-4ab692502fa9@redhat.com> (raw)
In-Reply-To: <8993ddbe-0a2f-feb0-9d1c-cbb5ea83bbc5@redhat.com>
On 7/29/19 5:51 PM, Paolo Bonzini wrote:
> On 29/07/19 23:46, John Snow wrote:
>>> @@ -111,15 +112,12 @@ static void dma_complete(DMAAIOCB *dbs, int ret)
>>> {
>>> trace_dma_complete(dbs, ret, dbs->common.cb);
>>>
>>> + assert(!dbs->acb && !dbs->bh);
>>> dma_blk_unmap(dbs);
>>> if (dbs->common.cb) {
>>> dbs->common.cb(dbs->common.opaque, ret);
>>> }
>>> qemu_iovec_destroy(&dbs->iov);
>>> - if (dbs->bh) {
>>> - qemu_bh_delete(dbs->bh);
>>> - dbs->bh = NULL;
>>> - }
>>
>> Now presumably handled by dma_aio_cancel,
>
> No, it simply could never happen. dma_complete is called here in dma_blk_cb:
>
> dbs->acb = NULL;
> dbs->offset += dbs->iov.size;
>
> if (dbs->sg_cur_index == dbs->sg->nsg || ret < 0) {
> dma_complete(dbs, ret);
> return;
> }
>
> and the only way to reach that when dbs->bh becomes non-NULL is through
> reschedule_dma, which clears dbs->bh before invoking dma_blk_cb.
>
>>> if (dbs->acb) {
>>> + /* This will invoke dma_blk_cb. */
>>
>> uhh, does it?
>
> Yes:
>
> /* Async version of aio cancel. The caller is not blocked if the acb implements
> * cancel_async, otherwise we do nothing and let the request normally complete.
> * In either case the completion callback must be called. */
>
Right, right -- the comment can SAY anything it likes about what the
"contract" is ...
OK, so it's more as if EITHER the cancel callback will invoke
dma_blk_cb, OR the acb object there will ... eventually ... through
normal execution.
OK, ok, ok. Getting it, slowly, slowly.
I think this comment is confusing, actually -- because dma_blk_cb might
not actually get invoked in the stack below this call. We only know it
might.
>> this is maybe where I got lost reading this code.
>> Isn't dbs->acb going to be what was returned from e.g.
>> dma_blk_read_io_func, which ultimately uses blk_aio_em_aiocb_info, that
>> has no cancel callback?
>
> Right therefore the I/O will complete and the callback will be invoked.
>
From the other email:
***oh***.
>> Well, here at least I am now on terra-firma that we're going to call the
>> original callback with ECANCELED, which is a step towards code that
>> isn't surprising my sensibilities.
>
> Good. :)
>
> Paolo
>
OK, this seems right to me then; the last puzzle piece is that Fam added
no-op returns for ECANCELED to the IDE originators of such DMA requests,
but now that I see the pathways beneath here I think it'd be /never/
right to ignore them.
If you cancel IDE's DMA out from under it, I think the IDE state machine
ought to treat it as an error, yes.
Thanks for the help, Paolo!
--js
next prev parent reply other threads:[~2019-07-29 22:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 21:34 [Qemu-devel] [PATCH] dma-helpers: ensure AIO callback is invoked after cancellation Paolo Bonzini
2019-07-29 21:46 ` John Snow
2019-07-29 21:51 ` Paolo Bonzini
2019-07-29 22:00 ` John Snow [this message]
2019-08-13 22:40 ` John Snow
2019-08-13 22:49 ` John Snow
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=8b7da43c-bf05-eef1-407d-4ab692502fa9@redhat.com \
--to=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).