All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: chris.mason@fusionio.com, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Deadlock in ctree.c?
Date: Fri, 22 Jun 2012 13:00:52 +0200	[thread overview]
Message-ID: <4FE45064.4090104@jan-o-sch.net> (raw)

While debugging my tree mod log, after several hours of successful iteration I
finally reached a dead lock. I got stacks with btrfs_next_leaf and
push_leaf_left and looked into those.

If I'm not mistaken, there is at least one deadlock situation between those two
(I'm currently thinking about a second one). Basically, the problem is that
btrfs_next_leaf has a leaf locked and wants a lock for the next (right) leaf,
while push_leaf_left has a lock on another leaf and wants a lock for the
previous (left) leaf.

Assume that we've got two roots (subvolumes), both referencing the same two
leafs in two really small trees:

          r1     r2
          |  \ /  |
          |   X   |
          |  / \  |
          l1     l2

Commented pseudo code that is meant to summarize the relevant code from ctree.c:

Thread A in push_leaf_left, path is currently r2->l2:
	btrfs_assert_tree_locked(path->nodes[1]); /* r2 */
	/* also holds a lock at path->nodes[0] -> l2 */
	left = read_node_slot(root, path->nodes[1], slot - 1); /* l1 */
	btrfs_tree_lock(left);
-> blocking to get lock on l1

Thread B in btrfs_next_leaf, path is currently r1->l1:
        path->keep_locks = 1;
	btrfs_search_slot(...); /* locks r1, l1 */
        level = 1;
        while ...
                slot = path->slots[level] + 1;
                next = read_block_for_search(... slot ...);
                btrfs_tree_read_lock(next); /* l2 */
-> blocking to get lock on l2

Any ideas on this one? Preferably hints to why I'm wrong :-)

Thanks!
-Jan

             reply	other threads:[~2012-06-22 11:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 11:00 Jan Schmidt [this message]
2012-06-22 13:30 ` Deadlock in ctree.c? Josef Bacik
2012-06-22 13:38   ` Jan Schmidt
2012-06-22 14:23     ` Josef Bacik
2012-06-22 14:26       ` Jan Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FE45064.4090104@jan-o-sch.net \
    --to=list.btrfs@jan-o-sch.net \
    --cc=chris.mason@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.