Bug 456320 - lockdep warning when revoking auth key while holding instantiated key sem
lockdep warning when revoking auth key while holding instantiated key sem
Status: CLOSED DUPLICATE of bug 453462
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jeff Layton
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-22 15:57 EDT by Jeff Layton
Modified: 2014-06-18 03:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-10 18:12:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch -- KEYS: fix lockdep warning when revoking auth key (1.17 KB, patch)
2008-07-23 06:46 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Jeff Layton 2008-07-22 15:57:58 EDT
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
Comment 1 Jeff Layton 2008-07-22 15:59:05 EDT
Actually, I'll take a crack at this before I shlep this off on David...
Comment 2 Jeff Layton 2008-07-23 06:46:33 EDT
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.
Comment 3 RHEL Product and Program Management 2008-07-23 06:54:00 EDT
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.
Comment 5 Jeff Layton 2008-08-10 18:12:00 EDT

*** This bug has been marked as a duplicate of bug 453462 ***

Note You need to log in before you can comment on or make changes to this bug.