This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 317241 - lockdep warnings while using request_key
lockdep warnings while using request_key
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Howells
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-03 15:51 EDT by Jeff Layton
Modified: 2014-06-18 03:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 15:28:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch -- in progress cifs patch that seems to trigger the problem (8.64 KB, patch)
2007-10-03 15:57 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Jeff Layton 2007-10-03 15:51:17 EDT
I've been working on getting kerberos upcalls working in CIFS and have been
using the keyctl API to try to implement it. While working with it, I've seen
lockdep warnings pop pretty regularly:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.23-0.214.rc8.git2.fc8 #1
-------------------------------------------------------
request-key/2508 is trying to acquire lock:
 (&key->sem){----}, at: [<ffffffff810f75f3>] key_revoke+0x15/0x3b

but task is already holding lock:
 (key_construction_sem){--..}, at: [<ffffffff810f7732>]
__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){--..}:
       [<ffffffff810553f5>] __lock_acquire+0xac0/0xcc9
       [<ffffffff81055a1d>] lock_acquire+0x5a/0x73
       [<ffffffff810f7732>] __key_instantiate_and_link+0x2f/0xd1
       [<ffffffff8104d42f>] down_write+0x3c/0x68
       [<ffffffff810f7732>] __key_instantiate_and_link+0x2f/0xd1
       [<ffffffff810f7815>] key_instantiate_and_link+0x41/0x6d
       [<ffffffff810f7829>] key_instantiate_and_link+0x55/0x6d
       [<ffffffff810f8cb2>] keyring_alloc+0x46/0x5e
       [<ffffffff810fa5b2>] alloc_uid_keyring+0x78/0xa6
       [<ffffffff81040890>] alloc_uid+0xa9/0x17d
       [<ffffffff81043e7e>] set_user+0x25/0xa9
       [<ffffffff810459d8>] sys_setuid+0x73/0x136
       [<ffffffff8100bbfe>] system_call+0x7e/0x83
       [<ffffffffffffffff>] 0xffffffffffffffff

-> #0 (&key->sem){----}:
       [<ffffffff81053bb0>] print_circular_bug_header+0xcc/0xd3
       [<ffffffff810552f6>] __lock_acquire+0x9c1/0xcc9
       [<ffffffff81055a1d>] lock_acquire+0x5a/0x73
       [<ffffffff810f75f3>] key_revoke+0x15/0x3b
       [<ffffffff8104d42f>] down_write+0x3c/0x68
       [<ffffffff810f75f3>] key_revoke+0x15/0x3b
       [<ffffffff810f7792>] __key_instantiate_and_link+0x8f/0xd1
       [<ffffffff810f91ed>] keyctl_instantiate_key+0xe0/0x137
       [<ffffffff8100bbfe>] system_call+0x7e/0x83
       [<ffffffffffffffff>] 0xffffffffffffffff

other info that might help us debug this:

1 lock held by request-key/2508:
 #0:  (key_construction_sem){--..}, at: [<ffffffff810f7732>]
__key_instantiate_and_link+0x2f/0xd1

stack backtrace:

Call Trace:
 [<ffffffff810537a0>] print_circular_bug_tail+0x69/0x72
 [<ffffffff81053bb0>] print_circular_bug_header+0xcc/0xd3
 [<ffffffff810552f6>] __lock_acquire+0x9c1/0xcc9
 [<ffffffff81055a1d>] lock_acquire+0x5a/0x73
 [<ffffffff810f75f3>] key_revoke+0x15/0x3b
 [<ffffffff8104d42f>] down_write+0x3c/0x68
 [<ffffffff810f75f3>] key_revoke+0x15/0x3b
 [<ffffffff810f7792>] __key_instantiate_and_link+0x8f/0xd1
 [<ffffffff810f91ed>] keyctl_instantiate_key+0xe0/0x137
 [<ffffffff8100bbfe>] system_call+0x7e/0x83

...the kernel is 2.6.23-0.214.rc8.git2.fc8, with an experimental patch for CIFS.
I'm suspect that I was doing something wrong with it, but I'm doing something
pretty simple. I'm registering a new key_type and then calling request_key()
during the session setup. The lockdep warning generally pops on the first mount
attempt.
Comment 2 Jeff Layton 2007-10-03 15:57:27 EDT
Created attachment 214971 [details]
patch -- in progress cifs patch that seems to trigger the problem

This patch is a (very early) work in progress CIFS patch that seems to trigger
this warning on current rawhide kernels. The calls into the keyring stuff are
pretty minimal, so this might be easily reproducible with a test kernel module
that simply tries to do a request_key() on a user keytype.
Comment 3 David Howells 2007-10-04 10:02:03 EDT
Try this: find the key_revoke() function in security/keys/key.c and change the 
down_write(...) to down_write_nested(..., 1).

The reason that the warning occurs is that during the key construction, there 
are two keys involved: the key being constructed and the authorisation key 
that lets the upcall process instantiate the first key.  Instantiation 
requires the key under construction to be write locked, then the construction 
semaphore write-locked, and then the auth key to be revoked - which requires 
its write lock to be held.

The problem is that lockdep isn't very clever and works by class rather than 
by object, and so doesn't know that two keys are guaranteed to be different 
and can be locked in that order, despite the intervening lock.  This isn't 
really lockdep's fault - being more thorough would require lockdep to use more 
resources.
Comment 4 Jeff Layton 2007-10-04 12:50:30 EDT
Thanks David -- that seems to eliminate the warning.
Comment 5 Jeff Layton 2007-10-04 12:52:40 EDT
Not sure how you want to proceed on this. Are you planning to push that patch
upstream, or just close this as NOTABUG?
Comment 6 Jeff Layton 2007-10-04 15:28:05 EDT
Ahh, looks like this has already been pushed upstream:

http://lkml.org/lkml/2007/9/17/209

I'll close it as such. Thanks for the help!

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