[LU-619] Recursive locking in ldlm_lock_change_resource

Related — Mon, 29 May 2017 02:33:57 +0000

I am using a vanilla kernel built with additional lock debugging. After mounting the Lustre, the first invocation of a simple 'ls' command results in a kernel warning of a recursive lock.

This is on the client side. Whether server 1.8 or 1.6 is used does not make a difference.

The log below was taken with the following server packages, and the full log is attached:

lustre: 1.8.6
kernel: patchless_client
build: jenkins-wc1--PRISTINE-2.6.18-238.12.1.el5_lustre.g266a955

=============================================
[ INFO: possible recursive locking detected ]
2.6.32.28-ml #8
---------------------------------------------
ls/1055 is trying to acquire lock:
(&res->lr_lock){....}, at: [<ffffffffa02e0a27>] ldlm_lock_change_resource+0x127/0x410 [ptlrpc]

but task is already holding lock:
(&res->lr_lock){....}, at: [<ffffffffa02db163>] lock_res_and_lock+0x63/0xf0 [ptlrpc]

other info that might help us debug this:
3 locks held by ls/1055:
#0: (&sb->s_type->i_mutex_key#13){..+.}, at: [<ffffffff810d4e25>] do_lookup+0xd5/0x240
#1: (&lock->l_lock){....}, at: [<ffffffffa02db126>] lock_res_and_lock+0x26/0xf0 [ptlrpc]
#2: (&res->lr_lock){....}, at: [<ffffffffa02db163>] lock_res_and_lock+0x63/0xf0 [ptlrpc]

stack backtrace:
Pid: 1055, comm: ls Not tainted 2.6.32.28-ml #8
Call Trace:
[<ffffffff8106a499>] __lock_acquire+0x1119/0x15d0
[<ffffffffa02e49d6>] ? ldlm_resource_get+0x696/0xc20 [ptlrpc]
[<ffffffff8106a9b7>] lock_acquire+0x67/0x90
[<ffffffffa02e0a27>] ? ldlm_lock_change_resource+0x127/0x410 [ptlrpc]
[<ffffffff8137be1c>] _spin_lock+0x2c/0x40
[<ffffffffa02e0a27>] ? ldlm_lock_change_resource+0x127/0x410 [ptlrpc]

Whamcloud Community JIRA

[LU-619] Recursive locking in ldlm_lock_change_resource