[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/5] blkdebug: fix racing condition when iterating on

From: Paolo Bonzini
Subject: Re: [PATCH 0/5] blkdebug: fix racing condition when iterating on
Date: Tue, 13 Apr 2021 09:50:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]