I'm working on the CIFS patch for RHEL5.3 which includes support for SPNEGO/Kerberos auth. The upcall uses the keys API. The first time that I do a krb5 mount after a reboot, the following lockdep warning pops. This seems to be similar to a problem I saw in Fedora last fall, and I think it was fixed upstream with the patchset that added asynchronous key support. I'm not sure how invasive or feasible that is for RHEL5.3 though. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.18-98.el5.jtltest.38debug #1 ------------------------------------------------------- cifs.spnego/2378 is trying to acquire lock: (&key->sem){----}, at: [<ffffffff80125af8>] key_revoke+0x15/0x3b but task is already holding lock: (key_construction_sem){--..}, at: [<ffffffff80125c37>] __key_instantiate_and_link+0x2f/0xd1 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (key_construction_sem){--..}: [<ffffffff800a817c>] __lock_acquire+0x9a9/0xadf [<ffffffff800a8a72>] lock_acquire+0x55/0x70 [<ffffffff80125c37>] __key_instantiate_and_link+0x2f/0xd1 [<ffffffff800a4e36>] down_write+0x3c/0x68 [<ffffffff80125c37>] __key_instantiate_and_link+0x2f/0xd1 [<ffffffff80125d1a>] key_instantiate_and_link+0x41/0x6d [<ffffffff80125d2e>] key_instantiate_and_link+0x55/0x6d [<ffffffff801271e7>] keyring_alloc+0x46/0x5e [<ffffffff80128a04>] alloc_uid_keyring+0x78/0xa6 [<ffffffff8000ada6>] kmem_cache_alloc+0xdf/0xeb [<ffffffff8009a957>] alloc_uid+0xa9/0x16f [<ffffffff8009d3cd>] set_user+0xf/0x98 [<ffffffff8009eb47>] sys_setuid+0x7d/0x154 [<ffffffff80060116>] system_call+0x7e/0x83 [<ffffffffffffffff>] 0xffffffffffffffff -> #0 (&key->sem){----}: [<ffffffff800a8092>] __lock_acquire+0x8bf/0xadf [<ffffffff800a8a72>] lock_acquire+0x55/0x70 [<ffffffff80125af8>] key_revoke+0x15/0x3b [<ffffffff800a4e36>] down_write+0x3c/0x68 [<ffffffff80125af8>] key_revoke+0x15/0x3b [<ffffffff80125c97>] __key_instantiate_and_link+0x8f/0xd1 [<ffffffff8012774b>] keyctl_instantiate_key+0x109/0x17a [<ffffffff800602a6>] tracesys+0xd5/0xdf [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 1 lock held by cifs.spnego/2378: #0: (key_construction_sem){--..}, at: [<ffffffff80125c37>] __key_instantiate_and_link+0x2f/0xd1 stack backtrace: Call Trace: [<ffffffff800a6a7b>] print_circular_bug_tail+0x65/0x6e [<ffffffff800a8092>] __lock_acquire+0x8bf/0xadf [<ffffffff800a8a72>] lock_acquire+0x55/0x70 [<ffffffff80125af8>] key_revoke+0x15/0x3b [<ffffffff800a4e36>] down_write+0x3c/0x68 [<ffffffff80125af8>] key_revoke+0x15/0x3b [<ffffffff80125c97>] __key_instantiate_and_link+0x8f/0xd1 [<ffffffff8012774b>] keyctl_instantiate_key+0x109/0x17a [<ffffffff800602a6>] tracesys+0xd5/0xdf
Actually, I'll take a crack at this before I shlep this off on David...
Created attachment 312459 [details] patch -- KEYS: fix lockdep warning when revoking auth key I cherry-picked this delta from the upstream patch that added the asynchronous interfaces to the keys API. It seems to fix the warning and doesn't seem to be dependent on the rest of the patch.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** This bug has been marked as a duplicate of bug 453462 ***