Changeset View
Changeset View
Standalone View
Standalone View
sys/arm/arm/trap-v6.c
Show First 20 Lines • Show All 302 Lines • ▼ Show 20 Lines | #endif | ||||
idx = FSR_TO_FAULT(fsr); | idx = FSR_TO_FAULT(fsr); | ||||
usermode = TRAPF_USERMODE(tf); /* Abort came from user mode? */ | usermode = TRAPF_USERMODE(tf); /* Abort came from user mode? */ | ||||
if (usermode) | if (usermode) | ||||
td->td_frame = tf; | td->td_frame = tf; | ||||
CTR6(KTR_TRAP, "%s: fsr %#x (idx %u) far %#x prefetch %u usermode %d", | CTR6(KTR_TRAP, "%s: fsr %#x (idx %u) far %#x prefetch %u usermode %d", | ||||
__func__, fsr, idx, far, prefetch, usermode); | __func__, fsr, idx, far, prefetch, usermode); | ||||
/* | /* | ||||
mmel: Also, i don't think that this is right place for KDTRACE_HOOKS.
Everything before line 353 (in… | |||||
Not Done Inline Actionsamd64 does the following: void trap_check(struct trapframe *frame) { #ifdef KDTRACE_HOOKS if (dtrace_trap_func != NULL && (*dtrace_trap_func)(frame, frame->tf_trapno) != 0) return; #endif trap(frame); } I have attempted to provide a solution that is as close to this, whilst minimizing changes. If I place the dtrace_trap_func call after pmap_fault() wouldn't the range checking mean that the kernel panics in my example malformed DTrace script? Whether dtrace_trap_func is called before or after FAULT_EA_IMPREC seems pretty mute to me. graeme.jenkinson_cl.cam.ac.uk: amd64 does the following:
```
void
trap_check(struct trapframe *frame)
{
#ifdef KDTRACE_HOOKS… | |||||
* Firstly, handle aborts that are not directly related to mapping. | * Firstly, handle aborts that are not directly related to mapping. | ||||
*/ | */ | ||||
if (__predict_false(idx == FAULT_EA_IMPREC)) { | if (__predict_false(idx == FAULT_EA_IMPREC)) { | ||||
abort_imprecise(tf, fsr, prefetch, usermode); | abort_imprecise(tf, fsr, prefetch, usermode); | ||||
return; | return; | ||||
} | } | ||||
Not Done Inline ActionsThis should be != 0 andrew: This should be `!= 0` | |||||
Not Done Inline ActionsIt's a bit ambiguous. But I can agree that dtrace_trap returns 0 if the trap should be handled in the usual way, so I'll change. graeme.jenkinson_cl.cam.ac.uk: It's a bit ambiguous. But I can agree that dtrace_trap returns 0 if the trap should be handled… | |||||
if (__predict_false(idx == FAULT_DEBUG)) { | if (__predict_false(idx == FAULT_DEBUG)) { | ||||
abort_debug(tf, fsr, prefetch, usermode, far); | abort_debug(tf, fsr, prefetch, usermode, far); | ||||
return; | return; | ||||
} | } | ||||
/* | /* | ||||
* ARM has a set of unprivileged load and store instructions | * ARM has a set of unprivileged load and store instructions | ||||
* (LDRT/LDRBT/STRT/STRBT ...) which are supposed to be used in other | * (LDRT/LDRBT/STRT/STRBT ...) which are supposed to be used in other | ||||
▲ Show 20 Lines • Show All 210 Lines • ▼ Show 20 Lines | |||||
{ | { | ||||
bool usermode; | bool usermode; | ||||
const char *mode; | const char *mode; | ||||
const char *rw_mode; | const char *rw_mode; | ||||
usermode = TRAPF_USERMODE(tf); | usermode = TRAPF_USERMODE(tf); | ||||
#ifdef KDTRACE_HOOKS | #ifdef KDTRACE_HOOKS | ||||
if (!usermode) { | if (!usermode) { | ||||
if (dtrace_trap_func != NULL && (*dtrace_trap_func)(tf, far)) | if (dtrace_trap_func != NULL && (*dtrace_trap_func)(tf, fsr)) | ||||
return (0); | return (0); | ||||
} | } | ||||
#endif | #endif | ||||
mode = usermode ? "user" : "kernel"; | mode = usermode ? "user" : "kernel"; | ||||
rw_mode = fsr & FSR_WNR ? "write" : "read"; | rw_mode = fsr & FSR_WNR ? "write" : "read"; | ||||
disable_interrupts(PSR_I|PSR_F); | disable_interrupts(PSR_I|PSR_F); | ||||
▲ Show 20 Lines • Show All 93 Lines • Show Last 20 Lines |
Also, i don't think that this is right place for KDTRACE_HOOKS.
Everything before line 353 (in original file, " if (__predict_false((td->td_pflags & TDP_NOFAULTING) != 0)) {"
is extreme hot path.