diff options
author | Olaf Faaland <[email protected]> | 2015-10-15 13:08:27 -0700 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2015-12-22 10:21:33 -0800 |
commit | 448d7aaabc55b43663c597b91b221bed982d81dd (patch) | |
tree | 89e12793ce08d38389662ff18c9336ba4be7fb9c /module/zfs/zap.c | |
parent | e0553a74adf1b1035e1ae25ca7feacacdeb93931 (diff) |
Identify locks flagged by lockdep
When running a kernel with CONFIG_LOCKDEP=y, lockdep reports possible
recursive locking in some cases and possible circular locking dependency
in others, within the SPL and ZFS modules.
This patch uses a mutex type defined in SPL, MUTEX_NOLOCKDEP, to mark
such mutexes when they are initialized. This mutex type causes
attempts to take or release those locks to be wrapped in lockdep_off()
and lockdep_on() calls to silence the dependency checker and allow the
use of lock_stats to examine contention.
For RW locks, it uses an analogous lock type, RW_NOLOCKDEP.
The goal is that these locks are ultimately changed back to type
MUTEX_DEFAULT or RW_DEFAULT, after the locks are annotated to reflect
their relationship (e.g. z_name_lock below) or any real problem with the
lock dependencies are fixed.
Some of the affected locks are:
tc_open_lock:
=============
This is an array of locks, all with same name, which txg_quiesce must
take all of in order to move txg to next state. All default to the same
lockdep class, and so to lockdep appears recursive.
zp->z_name_lock:
================
In zfs_rmdir,
dzp = znode for the directory (input to zfs_dirent_lock)
zp = znode for the entry being removed (output of zfs_dirent_lock)
zfs_rmdir()->zfs_dirent_lock() takes z_name_lock in dzp
zfs_rmdir() takes z_name_lock in zp
Since both dzp and zp are type znode_t, the locks have the same default
class, and lockdep considers it a possible recursive lock attempt.
l->l_rwlock:
============
zap_expand_leaf() sometimes creates two new zap leaf structures, via
these call paths:
zap_deref_leaf()->zap_get_leaf_byblk()->zap_leaf_open()
zap_expand_leaf()->zap_create_leaf()->zap_expand_leaf()->zap_create_leaf()
Because both zap_leaf_open() and zap_create_leaf() initialize
l->l_rwlock in their (separate) leaf structures, the lockdep class is
the same, and the linux kernel believes these might both be the same
lock, and emits a possible recursive lock warning.
Signed-off-by: Olaf Faaland <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes #3895
Diffstat (limited to 'module/zfs/zap.c')
-rw-r--r-- | module/zfs/zap.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/module/zfs/zap.c b/module/zfs/zap.c index c5ea392b6..4640fb98c 100644 --- a/module/zfs/zap.c +++ b/module/zfs/zap.c @@ -404,7 +404,7 @@ zap_create_leaf(zap_t *zap, dmu_tx_t *tx) ASSERT(RW_WRITE_HELD(&zap->zap_rwlock)); - rw_init(&l->l_rwlock, NULL, RW_DEFAULT, NULL); + rw_init(&l->l_rwlock, NULL, RW_NOLOCKDEP, NULL); rw_enter(&l->l_rwlock, RW_WRITER); l->l_blkid = zap_allocate_blocks(zap, 1); l->l_dbuf = NULL; |