Hello, This is split patchset of the RFC patches[1] to simplify btrfs locking and contains the following three patches.
0001-btrfs-Cleanup-extent_buffer-lockdep-code.patch 0002-btrfs-Use-separate-lockdep-class-keys-for-different-.patch 0003-btrfs-Simplify-extent_buffer-locking.patch For more info, please read the patch description on 0003 and the following two threads. http://thread.gmane.org/gmane.comp.file-systems.btrfs/9658 http://thread.gmane.org/gmane.linux.kernel/1116910 0001 and 0002 improve lockdep key assigning such that extent_buffer locks get different keys depending on the type (objectid) of the btrfs_root they belong to. I think this should provide enough lockdep annotation resolution to avoid spurious triggering but after applying this patchset, btrfs triggers several different locking dependency warnings. I've followed a couple of them and, to my untrained eyes, they seem to indicate genuine locking order problems in btrfs which were hidden till now because the custom locking was invisible to lockdep. Anyways, so, it seems locking fixes or at least lockdep annotation improvements will be needed. Chris, how do you want to proceed? Thanks. fs/btrfs/Makefile | 2 fs/btrfs/ctree.c | 16 +-- fs/btrfs/disk-io.c | 105 ++++++++++++++-------- fs/btrfs/disk-io.h | 21 ++-- fs/btrfs/extent-tree.c | 2 fs/btrfs/extent_io.c | 3 fs/btrfs/extent_io.h | 12 -- fs/btrfs/locking.c | 233 ------------------------------------------------- fs/btrfs/locking.h | 65 +++++++++++-- fs/btrfs/volumes.c | 2 10 files changed, 154 insertions(+), 307 deletions(-) -- tejun [1] http://article.gmane.org/gmane.comp.file-systems.btrfs/9658 -- 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
