From 5a0e3ad6af8660be21ca98a971cd00f331318c05 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Wed, 24 Mar 2010 17:04:11 +0900 Subject: include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo Guess-its-ok-by: Christoph Lameter Cc: Ingo Molnar Cc: Lee Schermerhorn --- security/keys/proc.c | 1 - security/keys/process_keys.c | 1 - 2 files changed, 2 deletions(-) (limited to 'security/keys') diff --git a/security/keys/proc.c b/security/keys/proc.c index 9d01021ca0c..706d63f4f18 100644 --- a/security/keys/proc.c +++ b/security/keys/proc.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c index 5c23afb31ec..06c2ccf26ed 100644 --- a/security/keys/process_keys.c +++ b/security/keys/process_keys.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include -- cgit v1.2.3-70-g09d2 From 93b4a44f3ad69520d605aace3f3486b8eb754b96 Mon Sep 17 00:00:00 2001 From: David Howells Date: Fri, 23 Apr 2010 13:18:00 -0400 Subject: keys: fix an RCU warning Fix the following RCU warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/request_key.c:116 invoked rcu_dereference_check() without protection! This was caused by doing: [root@andromeda ~]# keyctl newring fred @s 539196288 [root@andromeda ~]# keyctl request2 user a a 539196288 request_key: Required key not available Signed-off-by: David Howells Acked-by: Eric Dumazet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- security/keys/request_key.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'security/keys') diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 03fe63ed55b..ea97c3120d6 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -68,7 +68,8 @@ static int call_sbin_request_key(struct key_construction *cons, { const struct cred *cred = current_cred(); key_serial_t prkey, sskey; - struct key *key = cons->key, *authkey = cons->authkey, *keyring; + struct key *key = cons->key, *authkey = cons->authkey, *keyring, + *session; char *argv[9], *envp[3], uid_str[12], gid_str[12]; char key_str[12], keyring_str[3][12]; char desc[20]; @@ -112,10 +113,12 @@ static int call_sbin_request_key(struct key_construction *cons, if (cred->tgcred->process_keyring) prkey = cred->tgcred->process_keyring->serial; - if (cred->tgcred->session_keyring) - sskey = rcu_dereference(cred->tgcred->session_keyring)->serial; - else - sskey = cred->user->session_keyring->serial; + rcu_read_lock(); + session = rcu_dereference(cred->tgcred->session_keyring); + if (!session) + session = cred->user->session_keyring; + sskey = session->serial; + rcu_read_unlock(); sprintf(keyring_str[2], "%d", sskey); -- cgit v1.2.3-70-g09d2 From b59ec78cdcc57e02bc3dddfa7134a2f0fd15c34d Mon Sep 17 00:00:00 2001 From: David Howells Date: Tue, 27 Apr 2010 14:05:11 -0700 Subject: keys: don't need to use RCU in keyring_read() as semaphore is held keyring_read() doesn't need to use rcu_dereference() to access the keyring payload as the caller holds the key semaphore to prevent modifications from happening whilst the data is read out. This should solve the following warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/keyring.c:204 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by keyctl/2144: #0: (&key->sem){+++++.}, at: [] keyctl_read_key+0x9c/0xcf stack backtrace: Pid: 2144, comm: keyctl Not tainted 2.6.34-rc2-cachefs #113 Call Trace: [] lockdep_rcu_dereference+0xaa/0xb2 [] keyring_read+0x4d/0xe7 [] keyctl_read_key+0xac/0xcf [] sys_keyctl+0x75/0xb9 [] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells Cc: Herbert Xu Signed-off-by: Andrew Morton Signed-off-by: James Morris --- security/keys/keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'security/keys') diff --git a/security/keys/keyring.c b/security/keys/keyring.c index e814d2109f8..dd7cd0f8e13 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -201,7 +201,7 @@ static long keyring_read(const struct key *keyring, int loop, ret; ret = 0; - klist = rcu_dereference(keyring->payload.subscriptions); + klist = keyring->payload.subscriptions; if (klist) { /* calculate how much data we could return */ -- cgit v1.2.3-70-g09d2 From 03449cd9eaa4fa3a7faa4a59474bafe2e90bd143 Mon Sep 17 00:00:00 2001 From: David Howells Date: Tue, 27 Apr 2010 13:13:08 -0700 Subject: keys: the request_key() syscall should link an existing key to the dest keyring The request_key() system call and request_key_and_link() should make a link from an existing key to the destination keyring (if supplied), not just from a new key to the destination keyring. This can be tested by: ring=`keyctl newring fred @s` keyctl request2 user debug:a a keyctl request user debug:a $ring keyctl list $ring If it says: keyring is empty then it didn't work. If it shows something like: 1 key in keyring: 1070462727: --alswrv 0 0 user: debug:a then it did. request_key() system call is meant to recursively search all your keyrings for the key you desire, and, optionally, if it doesn't exist, call out to userspace to create one for you. If request_key() finds or creates a key, it should, optionally, create a link to that key from the destination keyring specified. Therefore, if, after a successful call to request_key() with a desination keyring specified, you see the destination keyring empty, the code didn't work correctly. If you see the found key in the keyring, then it did - which is what the patch is required for. Signed-off-by: David Howells Cc: James Morris Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- security/keys/request_key.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'security/keys') diff --git a/security/keys/request_key.c b/security/keys/request_key.c index ea97c3120d6..d737cea5347 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -339,8 +339,10 @@ static int construct_alloc_key(struct key_type *type, key_already_present: mutex_unlock(&key_construction_mutex); - if (dest_keyring) + if (dest_keyring) { + __key_link(dest_keyring, key_ref_to_ptr(key_ref)); up_write(&dest_keyring->sem); + } mutex_unlock(&user->cons_lock); key_put(key); *_key = key = key_ref_to_ptr(key_ref); @@ -431,6 +433,11 @@ struct key *request_key_and_link(struct key_type *type, if (!IS_ERR(key_ref)) { key = key_ref_to_ptr(key_ref); + if (dest_keyring) { + construct_get_dest_keyring(&dest_keyring); + key_link(dest_keyring, key); + key_put(dest_keyring); + } } else if (PTR_ERR(key_ref) != -EAGAIN) { key = ERR_CAST(key_ref); } else { -- cgit v1.2.3-70-g09d2 From d9a9b4aeea334e7912ce3d878d7f5cc6fdf1ffe4 Mon Sep 17 00:00:00 2001 From: David Howells Date: Fri, 30 Apr 2010 14:32:08 +0100 Subject: KEYS: Fix an RCU warning in the reading of user keys Fix an RCU warning in the reading of user keys: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by keyctl/3637: #0: (&key->sem){+++++.}, at: [] keyctl_read_key+0x9c/0xcf stack backtrace: Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18 Call Trace: [] lockdep_rcu_dereference+0xaa/0xb2 [] user_read+0x47/0x91 [] keyctl_read_key+0xac/0xcf [] sys_keyctl+0x75/0xb7 [] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells Acked-by: Serge Hallyn Signed-off-by: James Morris --- security/keys/user_defined.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'security/keys') diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c index 7c687d56822..e9aa0792965 100644 --- a/security/keys/user_defined.c +++ b/security/keys/user_defined.c @@ -199,7 +199,8 @@ long user_read(const struct key *key, char __user *buffer, size_t buflen) struct user_key_payload *upayload; long ret; - upayload = rcu_dereference(key->payload.data); + upayload = rcu_dereference_protected( + key->payload.data, rwsem_is_locked(&((struct key *)key)->sem)); ret = upayload->datalen; /* we can return the data as is */ -- cgit v1.2.3-70-g09d2 From cf8304e8f380903de3a15dc6ebd551c9e6cf1a21 Mon Sep 17 00:00:00 2001 From: David Howells Date: Tue, 4 May 2010 14:16:10 +0100 Subject: KEYS: Fix RCU handling in key_gc_keyring() key_gc_keyring() needs to either hold the RCU read lock or hold the keyring semaphore if it's going to scan the keyring's list. Given that it only needs to read the key list, and it's doing so under a spinlock, the RCU read lock is the thing to use. Furthermore, the RCU check added in e7b0a61b7929632d36cf052d9e2820ef0a9c1bfe is incorrect as holding the spinlock on key_serial_lock is not grounds for assuming a keyring's pointer list can be read safely. Instead, a simple rcu_dereference() inside of the previously mentioned RCU read lock is what we want. Reported-by: Serge E. Hallyn Signed-off-by: David Howells Acked-by: Serge Hallyn Acked-by: "Paul E. McKenney" Signed-off-by: James Morris --- security/keys/gc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'security/keys') diff --git a/security/keys/gc.c b/security/keys/gc.c index 19902319d09..a46e825cbf0 100644 --- a/security/keys/gc.c +++ b/security/keys/gc.c @@ -77,10 +77,10 @@ static bool key_gc_keyring(struct key *keyring, time_t limit) goto dont_gc; /* scan the keyring looking for dead keys */ - klist = rcu_dereference_check(keyring->payload.subscriptions, - lockdep_is_held(&key_serial_lock)); + rcu_read_lock(); + klist = rcu_dereference(keyring->payload.subscriptions); if (!klist) - goto dont_gc; + goto unlock_dont_gc; for (loop = klist->nkeys - 1; loop >= 0; loop--) { key = klist->keys[loop]; @@ -89,11 +89,14 @@ static bool key_gc_keyring(struct key *keyring, time_t limit) goto do_gc; } +unlock_dont_gc: + rcu_read_unlock(); dont_gc: kleave(" = false"); return false; do_gc: + rcu_read_unlock(); key_gc_cursor = keyring->serial; key_get(keyring); spin_unlock(&key_serial_lock); -- cgit v1.2.3-70-g09d2