Is this a race bug when releasing eb?

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

 



Assuming thread 1 (may be VFS want to release the page) wants to
release a CLEAN page and thus the eb attaching the page.
and thread 2 wants to access the eb and cow the eb.

Thread 1
               Thread 2

btree_releasepage

try_release_extent_buffer

release_extent_buffer
->if (atomic_dec_and_test(&eb->refs)) {
->spin_unlock(&eb->refs_lock);
 -------switch to thread 2 here------

               read_block_for_search

                btrfs_find_tree_block

     radix_tree_lookup && atomic_inc_not_zero

                  ................

                btrfs_mark_buffer_dirty(eb)

                ---------switch to thread 1 here ------

- >spin_lock(&tree->buffer_lock);
->radix_tree_delete(&tree->buffer,
 eb->start >> PAGE_CACHE_SHIFT);
->spin_unlock(&tree->buffer_lock);
-->btrfs_release_extent_buffer_page
-->trigger BUG_ON(extent_buffer_under_io(eb))!!!!


This is because Thread 2 can still find the eb while thread 1 has dec
the eb->refs to 0, so eventually trigger the BUG_ON.

I have triggered the BUG_ON while testing btrfs, but I am not sure if
the bug-on is rise by my guess above.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux