On Wed, Nov 8, 2017 at 2:50 PM, Pavel Butsykin <pbutsy...@virtuozzo.com> wrote: > On 08.11.2017 09:34, Sergio Lopez wrote: >> This was considered to be safe, as the completion function restarts the >> loop just after the call to qemu_bh_cancel. But, under certain access >> patterns and scheduling conditions, the loop may wrongly use a >> pre-fetched elem->state value, reading it as THREAD_QUEUED, and ending >> the completion function without having processed a pending TPE linked at >> pool->head: > > > I'm not quite sure that the pre-fetched is involved in this issue, > because pre-fetch reading a certain addresses should be invalidated by > write on another core to the same addresses. In our case write > req->state = THREAD_DONE should invalidate read req->state == THREAD_DONE. > I am inclined to think that there is a memory-reordering read with > write. It's a very real case for x86 and I don't see the reasons which > can prevent it: >
Yes, you're right. This is actually a memory reordering issue. I'm going to rewrite that paragraph. Thanks Pavel.