aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86
diff options
context:
space:
mode:
authorSteven Rostedt <srostedt@redhat.com>2009-02-10 11:53:23 -0500
committerIngo Molnar <mingo@elte.hu>2009-02-11 04:06:13 -0500
commitf47a454db9129d2e61b224a40f4365cdd4f83042 (patch)
tree106e1d50cd407aef60be58711c9ef90a3b4c28db /arch/x86
parent7d6d49b1f5551b87bd59c66c10747b89367760fd (diff)
tracing, x86: fix constraint for parent variable
The constraint used for retrieving and restoring the parent function pointer is incorrect. The parent variable is a pointer, and the address of the pointer is modified by the asm statement and not the pointer itself. It is incorrect to pass it in as an output constraint since the asm will never update the pointer. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch/x86')
-rw-r--r--arch/x86/kernel/ftrace.c9
1 files changed, 4 insertions, 5 deletions
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 9d549e4fe880..231bdd3c5b1c 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -488,8 +488,8 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
488 * ignore such a protection. 488 * ignore such a protection.
489 */ 489 */
490 asm volatile( 490 asm volatile(
491 "1: " _ASM_MOV " (%[parent_old]), %[old]\n" 491 "1: " _ASM_MOV " (%[parent]), %[old]\n"
492 "2: " _ASM_MOV " %[return_hooker], (%[parent_replaced])\n" 492 "2: " _ASM_MOV " %[return_hooker], (%[parent])\n"
493 " movl $0, %[faulted]\n" 493 " movl $0, %[faulted]\n"
494 "3:\n" 494 "3:\n"
495 495
@@ -501,9 +501,8 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
501 _ASM_EXTABLE(1b, 4b) 501 _ASM_EXTABLE(1b, 4b)
502 _ASM_EXTABLE(2b, 4b) 502 _ASM_EXTABLE(2b, 4b)
503 503
504 : [parent_replaced] "=r" (parent), [old] "=r" (old), 504 : [old] "=r" (old), [faulted] "=r" (faulted)
505 [faulted] "=r" (faulted) 505 : [parent] "r" (parent), [return_hooker] "r" (return_hooker)
506 : [parent_old] "0" (parent), [return_hooker] "r" (return_hooker)
507 : "memory" 506 : "memory"
508 ); 507 );
509 508
. This is a short duration placeholder that causes any attempt at re-requesting the key whilst it exists to fail with error ENOKEY. This is provided to prevent excessive repeated spawning of /sbin/request-key processes for a key that will never be obtainable. Should the /sbin/request-key process exit anything other than 0 or die on a signal, the key under construction will be automatically negatively instantiated for a short amount of time. ==================== THE SEARCH ALGORITHM ==================== A search of any particular keyring proceeds in the following fashion: (1) When the key management code searches for a key (keyring_search_aux) it firstly calls key_permission(SEARCH) on the keyring it's starting with, if this denies permission, it doesn't search further. (2) It considers all the non-keyring keys within that keyring and, if any key matches the criteria specified, calls key_permission(SEARCH) on it to see if the key is allowed to be found. If it is, that key is returned; if not, the search continues, and the error code is retained if of higher priority than the one currently set. (3) It then considers all the keyring-type keys in the keyring it's currently searching. It calls key_permission(SEARCH) on each keyring, and if this grants permission, it recurses, executing steps (2) and (3) on that keyring. The process stops immediately a valid key is found with permission granted to use it. Any error from a previous match attempt is discarded and the key is returned. When search_process_keyrings() is invoked, it performs the following searches until one succeeds: (1) If extant, the process's thread keyring is searched. (2) If extant, the process's process keyring is searched. (3) The process's session keyring is searched. (4) If the process has assumed the authority associated with a request_key() authorisation key then: (a) If extant, the calling process's thread keyring is searched. (b) If extant, the calling process's process keyring is searched. (c) The calling process's session keyring is searched. The moment one succeeds, all pending errors are discarded and the found key is returned. Only if all these fail does the whole thing fail with the highest priority error. Note that several errors may have come from LSM. The error priority is: EKEYREVOKED > EKEYEXPIRED > ENOKEY EACCES/EPERM are only returned on a direct search of a specific keyring where the basal keyring does not grant Search permission.