lkml.org 
[lkml]   [2011]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC PATCHSET] btrfs: Simplify extent_buffer locking
Date
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


\
 
 \ /
  Last update: 2011-03-24 18:45    [W:3.094 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site