mirror of
https://github.com/reactos/reactos.git
synced 2025-04-05 13:11:22 +00:00
distinguish kmode and umode alertability
svn path=/trunk/; revision=13581
This commit is contained in:
parent
b24437e1ae
commit
4f0495a525
4 changed files with 24 additions and 26 deletions
|
@ -8,7 +8,7 @@ typedef ULONG KAFFINITY, *PKAFFINITY;
|
|||
/*
|
||||
* Various other types (all quite pointless)
|
||||
*/
|
||||
typedef CCHAR KPROCESSOR_MODE;
|
||||
typedef UCHAR KPROCESSOR_MODE;
|
||||
typedef UCHAR KIRQL;
|
||||
typedef KIRQL* PKIRQL;
|
||||
typedef ULONG IO_ALLOCATION_ACTION;
|
||||
|
|
|
@ -73,7 +73,7 @@ typedef struct _KTHREAD
|
|||
|
||||
/* Thread state (one of THREAD_STATE_xxx constants below) */
|
||||
UCHAR State; /* 2D */
|
||||
UCHAR Alerted[2]; /* 2E */
|
||||
BOOLEAN Alerted[2]; /* 2E */
|
||||
UCHAR Iopl; /* 30 */
|
||||
UCHAR NpxState; /* 31 */
|
||||
CHAR Saturation; /* 32 */
|
||||
|
|
|
@ -37,14 +37,11 @@ KeTestAlertThread(IN KPROCESSOR_MODE AlertMode)
|
|||
OldIrql = KeAcquireDispatcherDatabaseLock();
|
||||
KiAcquireSpinLock(&Thread->ApcQueueLock);
|
||||
|
||||
/* NOTE: Albert Almeida claims Alerted[1] is never used. Two kind of
|
||||
* alerts _do_ seem useless. -Gunnar
|
||||
*/
|
||||
OldState = Thread->Alerted[0];
|
||||
OldState = Thread->Alerted[AlertMode];
|
||||
|
||||
/* If the Thread is Alerted, Clear it */
|
||||
if (OldState) {
|
||||
Thread->Alerted[0] = FALSE;
|
||||
Thread->Alerted[AlertMode] = FALSE;
|
||||
} else if ((AlertMode == UserMode) && (!IsListEmpty(&Thread->ApcState.ApcListHead[UserMode]))) {
|
||||
/* If the mode is User and the Queue isn't empty, set Pending */
|
||||
Thread->ApcState.UserApcPending = TRUE;
|
||||
|
@ -65,20 +62,19 @@ KeAlertThread(PKTHREAD Thread, KPROCESSOR_MODE AlertMode)
|
|||
oldIrql = KeAcquireDispatcherDatabaseLock();
|
||||
|
||||
|
||||
/* Return if thread is already alerted.
|
||||
* NOTE: Albert Almeida claims Alerted[1] is never used. Two kind of
|
||||
* alerts _do_ seem useless. -Gunnar
|
||||
*/
|
||||
if (Thread->Alerted[0] == FALSE)
|
||||
/* Return if thread is already alerted. */
|
||||
if (Thread->Alerted[AlertMode] == FALSE)
|
||||
{
|
||||
Thread->Alerted[0] = TRUE;
|
||||
|
||||
if (Thread->State == THREAD_STATE_BLOCKED &&
|
||||
Thread->WaitMode == AlertMode &&
|
||||
(AlertMode == KernelMode || Thread->WaitMode == AlertMode) &&
|
||||
Thread->Alertable)
|
||||
{
|
||||
KiAbortWaitThread(Thread, STATUS_ALERTED);
|
||||
}
|
||||
else
|
||||
{
|
||||
Thread->Alerted[AlertMode] = TRUE;
|
||||
}
|
||||
}
|
||||
|
||||
KeReleaseDispatcherDatabaseLock(oldIrql);
|
||||
|
@ -124,11 +120,12 @@ NtAlertThread (IN HANDLE ThreadHandle)
|
|||
return(Status);
|
||||
}
|
||||
|
||||
/* FIXME: should we always use UserMode here, even if the ntoskrnl exported
|
||||
* ZwAlertThread was called?
|
||||
* -Gunnar
|
||||
*/
|
||||
KeAlertThread((PKTHREAD)Thread, PreviousMode);
|
||||
/* do an alert depending on the processor mode. If some kmode code wants to
|
||||
enforce a umode alert it should call KeAlertThread() directly. If kmode
|
||||
code wants to do a kmode alert it's sufficient to call it with Zw or just
|
||||
use KeAlertThread() directly */
|
||||
|
||||
KeAlertThread(&Thread->Tcb, PreviousMode);
|
||||
|
||||
ObDereferenceObject(Thread);
|
||||
return(STATUS_SUCCESS);
|
||||
|
@ -142,11 +139,12 @@ NTSTATUS
|
|||
STDCALL
|
||||
NtTestAlert(VOID)
|
||||
{
|
||||
KPROCESSOR_MODE PreviousMode;
|
||||
|
||||
PreviousMode = ExGetPreviousMode();
|
||||
|
||||
/* Check and Alert Thread if needed */
|
||||
if (KeTestAlertThread(KeGetPreviousMode())) {
|
||||
return STATUS_ALERTED;
|
||||
} else {
|
||||
return STATUS_SUCCESS;
|
||||
}
|
||||
|
||||
return KeTestAlertThread(PreviousMode) ? STATUS_ALERTED : STATUS_SUCCESS;
|
||||
}
|
||||
|
||||
|
|
|
@ -134,7 +134,7 @@ typedef LONG KPRIORITY;
|
|||
typedef UCHAR KIRQL, *PKIRQL;
|
||||
typedef ULONG_PTR KSPIN_LOCK, *PKSPIN_LOCK;
|
||||
typedef ULONG KAFFINITY, *PKAFFINITY;
|
||||
typedef CCHAR KPROCESSOR_MODE;
|
||||
typedef UCHAR KPROCESSOR_MODE;
|
||||
|
||||
typedef enum _MODE {
|
||||
KernelMode,
|
||||
|
|
Loading…
Reference in a new issue