All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Emanuele Giuseppe Esposito <eesposit@redhat.com>, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH 0/5] blkdebug: fix racing condition when iterating on
Date: Tue, 13 Apr 2021 09:50:52 +0200	[thread overview]
Message-ID: <4ca1d18d-0a0e-ff52-8935-5ca9fad179cd@redhat.com> (raw)
In-Reply-To: <20210408155913.53235-1-eesposit@redhat.com>

On 08/04/21 17:59, Emanuele Giuseppe Esposito wrote:
> When qemu_coroutine_enter is executed in a loop
> (even QEMU_FOREACH_SAFE), the new routine can modify the list,
> for example removing an element, causing problem when control
> is given back to the caller that continues iterating on the same list.
> 
> Patch 1 solves the issue in blkdebug_debug_resume by restarting
> the list walk after every coroutine_enter if list has to be fully iterated.
> Patches 2,3,4 aim to fix blkdebug_debug_event by gathering
> all actions that the rules make in a counter and invoking
> the respective coroutine_yeld only after processing all requests.
> Patch 5 adds a lock to protect rules and suspended_reqs.

Patch 5 is somewhat independent of the others; right now everything 
works because it's protected by the AioContext lock.

On the other hand the scenarios in patches 1-4 are bugs even without 
patch 5.  They become more obvious if you see an explicit unlock/lock 
pair within QTAILQ_FOREACH_SAFE, but they can happen already with just a 
qemu_coroutine_yield or qemu_coroutine_enter within the iteration.

Paolo



      parent reply	other threads:[~2021-04-13  7:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 15:59 [PATCH 0/5] blkdebug: fix racing condition when iterating on Emanuele Giuseppe Esposito
2021-04-08 15:59 ` [PATCH 1/5] blkdebug: refactor removal of a suspended request Emanuele Giuseppe Esposito
2021-04-08 15:59 ` [PATCH 2/5] blkdebug: move post-resume handling to resume_req_by_tag Emanuele Giuseppe Esposito
2021-04-08 15:59 ` [PATCH 3/5] blkdebug: track all actions Emanuele Giuseppe Esposito
2021-04-08 15:59 ` [PATCH 4/5] blkdebug: do not suspend in the middle of QLIST_FOREACH_SAFE Emanuele Giuseppe Esposito
2021-04-13  7:48   ` Paolo Bonzini
2021-04-08 15:59 ` [PATCH 5/5] blkdebug: protect rules and suspended_reqs with a lock Emanuele Giuseppe Esposito
2021-04-13  7:50 ` Paolo Bonzini [this message]

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=4ca1d18d-0a0e-ff52-8935-5ca9fad179cd@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=eesposit@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.