BUG? a possible bug for the absence of memory barrier

BUG? a possible bug for the absence of memory barrier

[홍신 shin hong]

Hello. I am reporting possible bugs caused
by the absence of memory barriers.

Please examine this issue and let me know your opinion.

In add_async_extent(), an async_extent object is allocated and initialized
and then links to &cow->extents.

However, since there is no memory barrier
between the initialization and the linking to the list,
these two operations are executed opposite order.
And the re-ordering might result race condition.

The similar issue is also in join_transaction().

Thank you

Sincerely

Shin Hong

Re: BUG? a possible bug for the absence of memory barrier

[Chris Mason]

On Thu, Sep 10, 2009 at 12:15:24AM +0900, =ED=99=8D=EC=8B=A0 shin hong =
wrote:
> Hello. I am reporting possible bugs caused
> by the absence of memory barriers.
>=20
> Please examine this issue and let me know your opinion.
>=20
> In add_async_extent(), an async_extent object is allocated and initia=
lized
> and then links to &cow->extents.

Memory barriers have an impact when there are multiple CPUs accessing
the same data structures at the same time.  In the case of
add_async_extent only one worker thread is working on that list at a
time.

>=20
> However, since there is no memory barrier
> between the initialization and the linking to the list,
> these two operations are executed opposite order.
> And the re-ordering might result race condition.
>=20
> The similar issue is also in join_transaction().

In join_transaction, that list is protected by the trans_mutex.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html