Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows
block_group = btrfs_lookup_block_group(root->fs_info, ins->objectid); cache_block_group(block_group); btrfs_lookup_block_group releases a spin_lock at the end so the writes in spin_lock cannot get out. Another thing is that block_group is returned from this function which is being passed to cache_block_group.This means there is a causal relationship between cache->cached variable and the block_group returned.So x86 or x86-64 should not reorder it.However,Alpha might reorder it.So memory barrier maybe required in Alpha case. Again,in function find_free_extent the code snippet is if (loop > LOOP_CACHING_NOWAIT || (loop > LOOP_FIND_IDEAL && atomic_read(&space_info->caching_threads) < 2)) { ret = cache_block_group(block_group); BUG_ON(ret); } In this code also I believe the architecture should not reorder the read with atomic_read of caching_threads because of if condition and x86-64 not doing read reordering from software point of view.Also,any writes that happened before the if condition should not probably remain in the write buffer because the there should not be reordering done with anything inside the 'if' condition. I am also not sure of the barrier block_group_cache_done.Any reasoning for that would also be helpful. Am I missing something here?Please clarify.I am doing some dynamic analysis to find out possible barrier synchronization problems in btrfs, if any?Any help would be great. Thanks. Abhinav. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html