Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.8.0
-
TOSS 2.3-6 / 2.6.32-504.16.2.1chaos.ch5.3.x86_64.debug
(CONFIG_LOCKDEP=y)
-
3
-
9223372036854775807
Description
Upon mounting MDT, lockdep emits a warning:
[ INFO: possible recursive locking detected ]
2.6.32-504.16.2.1chaos.ch5.3.x86_64.debug #1
---------------------------------------------
llog_process_th/22500 is trying to acquire lock:
(&mo->oo_sem){++++++}, at: [<ffffffffa10e6c01>] osd_object_write_lock+0x61/0x70 [osd_zfs]
but task is already holding lock:
(&mo->oo_sem){++++++}, at: [<ffffffffa10e6c01>] osd_object_write_lock+0x61/0x70 [osd_zfs]
other info that might help us debug this:
1 lock held by llog_process_th/22500:
#0: (&mo->oo_sem){++++++}, at: [<ffffffffa10e6c01>] osd_object_write_lock+0x61/0x70 [osd_zfs]
stack backtrace:
Pid: 22500, comm: llog_process_th Tainted: G W --------------- 2.6.32-504.16.2.1chaos.ch5.3.x86_64.debug #1
Call Trace:
[<ffffffff810bfe90>] ? __lock_acquire+0x11b0/0x1560
[<ffffffffa0abc225>] ? lu_object_put+0x135/0x3b0 [obdclass]
[<ffffffff810c02e4>] ? lock_acquire+0xa4/0x120
[<ffffffffa10e6c01>] ? osd_object_write_lock+0x61/0x70 [osd_zfs]
[<ffffffff815603b1>] ? down_write+0x61/0xb0
[<ffffffffa10e6c01>] ? osd_object_write_lock+0x61/0x70 [osd_zfs]
[<ffffffffa10e6c01>] ? osd_object_write_lock+0x61/0x70 [osd_zfs]
[<ffffffffa0a9b374>] ? dt_write_lock.clone.4+0x24/0xc0 [obdclass]
[<ffffffffa0a9eea4>] ? __local_file_create+0x6b4/0xbb0 [obdclass]
[<ffffffffa0a9f673>] ? local_file_find_or_create+0x123/0x190 [obdclass]
[<ffffffffa1075706>] ? lquota_disk_dir_find_create+0x136/0x610 [lquota]
[<ffffffffa108e056>] ? qmt_device_prepare+0xb6/0x200 [lquota]
[<ffffffffa11c4387>] ? mdt_quota_init+0xdb7/0x1360 [mdt]
[<ffffffffa11cbb65>] ? mdt_device_alloc+0x1095/0x1260 [mdt]
[<ffffffffa0aa242f>] ? obd_setup+0x1bf/0x290 [obdclass]
[<ffffffffa0aa2758>] ? class_setup+0x258/0x930 [obdclass]
[<ffffffffa0aa9011>] ? class_process_config+0x1151/0x26d0 [obdclass]
[<ffffffff8118c983>] ? cache_alloc_debugcheck_after+0xf3/0x230
[<ffffffff81545b30>] ? kmemleak_alloc+0x20/0xd0
[<ffffffff8118ffdb>] ? __kmalloc+0x21b/0x330
[<ffffffffa0aabe2f>] ? class_config_llog_handler+0xa8f/0x1fb0 [obdclass]
[<ffffffffa0aabfb6>] ? class_config_llog_handler+0xc16/0x1fb0 [obdclass]
[<ffffffffa0a6f212>] ? llog_process_thread+0x932/0xfc0 [obdclass]
[<ffffffffa0a6fde8>] ? llog_process_thread_daemonize+0x48/0x70 [obdclass]
[<ffffffffa0a6fda0>] ? llog_process_thread_daemonize+0x0/0x70 [obdclass]
[<ffffffff810a4cbe>] ? kthread+0x9e/0xc0
[<ffffffff8100c30a>] ? child_rip+0xa/0x20
[<ffffffff8100bb10>] ? restore_args+0x0/0x30
[<ffffffff810a4c20>] ? kthread+0x0/0xc0
[<ffffffff8100c300>] ? child_rip+0x0/0x20
I believe this occurs because __local_file_create() calls dt_write_lock(env, dto, 0) followed by dt_write_lock(env, parent, 0); since dto and parent are both dt_object, and no lock class was explicitly set, the class for the embedded locks are the same and based on the class it appears to be a recursive lock attempt.
So, I believe the warning to be a false positive.
The actual stack, appears to me to be:
down_write
osd_object_write_lock [osd_zfs]
do_write_lock AKA osd_object_write_lock
dt_write_lock
__local_file_create [obdclass]
local_file_find_or_create [obdclass]
lquota_disk_dir_find_create [lquota]
qmt_device_prepare [lquota]
ldo_prepare AKA qmt_device_prepare
mdt_quota_init [mdt]
mdt_init0
mdt_device_alloc [mdt]
I'll submit a patch. It does make the symptom go away, but it would be good for someone to confirm my diagnosis.