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 -- 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
Chris Mason
2009-Sep-10 20:38 UTC
Re: BUG? a possible bug for the absence of memory barrier
On Thu, Sep 10, 2009 at 12:15:24AM +0900, 홍신 shin hong wrote:> 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.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.> > 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().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