[ros-bugs] [Bug 5955] kernel32_winetest:thread asserts with 'OldIrql == PASSIVE_LEVEL' failed

[ReactOS.Bugzilla at reactos.org]

http://www.reactos.org/bugzilla/show_bug.cgi?id=5955


bugboy <martinmnet at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martinmnet at hotmail.com




--- Comment #2 from bugboy <martinmnet at hotmail.com>  2011-04-23 15:44:26 CET ---
This is caused by the following.

ntdll file test request a asynchronous read on a just created pipe.
no pipe data is yet available and NpfsRead queues the request to a kernel
thread waiting on an event to be set by NpfsWrite.
Then ntdll file writes to the pipe. NpfsWrite acquires a FastMutex before
writing the data to its internal buffer,
it then sets the event and releases FastMutex.
If at the time before the IRQL is dropped to PASSIVE_LEVEL by release of the
FastMutex, the kernel thread handling the event runs. 
The read is done and the thread completes the IRP. 
Now since this is ansych and an apc routine was passed in the read,
IopCompleteRequest requests an APC to the thread 
that requested the read. When the thread that was releaseing the FastMutex
finally wakes it has an APC pending and 
since it never dropped to PASSIVE_LEVEL the OldIrql is at APC_LEVEL and so the
assert is hit.
So the question is, 

1. Should ExReleaseFastMutex lower the IRQL before calling
KeSetEventBoostPriority, which can cause the switch to
the kernel thread handling the NpfsRead request?
2. Should the KiExitDispatcher check that its at passive level before calling
KiDeliverApc? If so requesting an software interrupt at APC_LEVEL. 
3. Or should it be both?

Reading NT's APC Dispatcher at http://drdobbs.com/184416590 it looks like
option 2.


-- 
Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.