[LU-619] Recursive locking in ldlm_lock_change_resource

• Type: Bug
• Resolution: Cannot Reproduce
• Priority: Minor
• Affects Version/s: Lustre 1.8.6
• Environment: Client: Lustre b1_8 Git 999530e, Linux 2.6.32.8
• Severity: 3
• Assignee: WC Triage
• Reporter: Mark Hills

Description

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]

Issue Links

• is related to: LU-811 possible recursive locking detected on client
• Trackbacks: Lustre 1.8.x known issues tracker While testing against Lustre b18 branch, we would hit known bugs which were already reported in Lustre Bugzilla https://bugzilla.lustre.org/. In order to move away from relying on Bugzilla, we would create a JIRA