From: ChenLiang <chenliang88@huawei.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"stefanha@redhat.com" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] ide: fix double free
Date: Wed, 2 Jul 2014 19:33:19 +0800 [thread overview]
Message-ID: <53B3EDFF.6010309@huawei.com> (raw)
In-Reply-To: <53B3DBFD.1090009@redhat.com>
On 2014/7/2 18:16, Paolo Bonzini wrote:
> Il 02/07/2014 11:46, Gonglei (Arei) ha scritto:
>> Hi, Paolo. We have tested your above patch, and it works well for us.
>
> I'm still not sure where the fix is. I jotted the patch quickly, but I'd rather understand it better before submitting it. Here is it again:
>
> --- a/dma-helpers.c
> +++ b/dma-helpers.c
> @@ -181,15 +181,15 @@ static void dma_aio_cancel(BlockDriverAIOCB *acb)
> trace_dma_aio_cancel(dbs);
>
> + dbs->in_cancel = true;
> if (dbs->acb) {
> BlockDriverAIOCB *acb = dbs->acb;
> dbs->acb = NULL;
> - dbs->in_cancel = true;
> bdrv_aio_cancel(acb);
> - dbs->in_cancel = false;
> }
> dbs->common.cb = NULL;
> dma_complete(dbs, 0);
> + qemu_aio_release(dbs);
> }
>
Hmm, dbs->in_cancel will be true always. Although this will avoid freeing dbs by dma_comlete.
But it maybe a mistake.
> static const AIOCBInfo dma_aiocb_info = {
>
> and here is dma_complete:
>
> static void dma_complete(DMAAIOCB *dbs, int ret)
> {
> trace_dma_complete(dbs, ret, dbs->common.cb);
> dma_bdrv_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;
> }
> if (!dbs->in_cancel) {
> /* Requests may complete while dma_aio_cancel is in progress.
> * this case, the AIOCB should not be released because it is
> * still referenced by dma_aio_cancel. */
> qemu_aio_release(dbs);
> }
> }
>
> The qemu_aio_release call obviously happened during the second dma_complete call.
>
> However, the second dma_complete call does not call the callback, and even if dma_bdrv_unmap resulted in a call to continue_after_map_failure, the bottom half would be cancelled immediately. So we changed from:
>
> dbs->in_cancel = false;
>
> /* dma_complete calls dma_bdrv_unmap */
> for (i = 0; i < dbs->iov.niov; ++i) {
> /* might schedule dbs->bh */
> dma_memory_unmap(dbs->sg->as, dbs->iov.iov[i].iov_base,
> dbs->iov.iov[i].iov_len, dbs->dir,
> dbs->iov.iov[i].iov_len);
> }
> qemu_iovec_reset(&dbs->iov);
>
> /* back to dma_complete, dbs->common.cb == NULL */
> qemu_iovec_destroy(&dbs->iov);
> if (dbs->bh) {
> /* dbs->bh now unscheduled, so it will never run */
> qemu_bh_delete(dbs->bh);
> dbs->bh = NULL;
> }
> /* dbs->in_cancel is false here. */
> if (!dbs->in_cancel) {
> /* Requests may complete while dma_aio_cancel is in progress.
> * this case, the AIOCB should not be released because it is
> * still referenced by dma_aio_cancel. */
> qemu_aio_release(dbs);
> }
>
> to
>
> dbs->in_cancel = false;
>
> /* dma_complete calls dma_bdrv_unmap */
> for (i = 0; i < dbs->iov.niov; ++i) {
> /* might schedule dbs->bh */
> dma_memory_unmap(dbs->sg->as, dbs->iov.iov[i].iov_base,
> dbs->iov.iov[i].iov_len, dbs->dir,
> dbs->iov.iov[i].iov_len);
> }
> qemu_iovec_reset(&dbs->iov);
>
> /* back to dma_complete, dbs->common.cb == NULL */
> qemu_iovec_destroy(&dbs->iov);
> if (dbs->bh) {
> /* dbs->bh now unscheduled, so it will never run */
> qemu_bh_delete(dbs->bh);
> dbs->bh = NULL;
> }
>
> /* after the patch dbs->in_cancel is true, the if never triggers */
> if (!dbs->in_cancel) {
> /* Requests may complete while dma_aio_cancel is in progress.
> * this case, the AIOCB should not be released because it is
> * still referenced by dma_aio_cancel. */
> qemu_aio_release(dbs);
> }
>
> /* back to dma_aio_cancel */
> qemu_aio_release(dbs);
>
> This doesn't make sense to me. Can you find out where I'm wrong?
>
> Paolo
>
> .
>
next prev parent reply other threads:[~2014-07-02 11:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 8:50 [Qemu-devel] [PATCH] ide: fix double free arei.gonglei
2014-07-02 9:04 ` Paolo Bonzini
2014-07-02 9:24 ` ChenLiang
2014-07-02 9:25 ` Paolo Bonzini
2014-07-02 9:46 ` Gonglei (Arei)
2014-07-02 10:16 ` Paolo Bonzini
2014-07-02 11:12 ` ChenLiang
2014-07-02 11:24 ` Paolo Bonzini
2014-07-02 11:33 ` ChenLiang [this message]
2014-07-02 11:40 ` Paolo Bonzini
2014-07-02 11:57 ` ChenLiang
2014-07-02 12:19 ` Paolo Bonzini
2014-07-02 12:46 ` 陈梁
2014-07-02 12:54 ` 陈梁
2014-07-02 13:09 ` Paolo Bonzini
2014-07-03 2:23 ` ChenLiang
2014-07-03 10:41 ` Paolo Bonzini
2014-07-07 8:12 ` ChenLiang
2014-07-07 12:38 ` 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=53B3EDFF.6010309@huawei.com \
--to=chenliang88@huawei.com \
--cc=arei.gonglei@huawei.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=weidong.huang@huawei.com \
/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).