ExAcquireFastMutex raises IRQL to APC_LEVEL. After acquring the mutex some
IoCallDriver is needed in my driver, but calling IoCallDriver by holding any
lock will be caught by driver verifier saying IRQL is not same before and
after IoCalldriver. I know from varous pundits that IoCallDriver must not be
used while holding a spin lock, yet it seems that driver verifier forces it
for any lock. Anyway, I need to use IoCallDriver while holding the mutex, so
to cheat driver verifier I lower the IRQL to PASSIVE_LEVEL then do my
IoCallDriver stuff and then raise IRQL back to APC_LEVEL for releasing the
mutex. It seems pretty well cheating driver verifier. I don’t want to invent
my own locking mechanism, could anybody shed some light on to this matter?
For example, after lowering the irql if another thread tries to acquire that
mutex what will happen specially with SMP machine? To handle this scenario
what should be the safe way?
You need to fix your synchronization so that you don’t have to be
holding the lock while another I/O request is running.
Instead of using a lock to protect the region that sends I/O, you can
use queues to ensure that you’re not going to have two threads trying to
access the same resource. When one thread has left the protected region
it can pickup the next I/O from the queue and process it.
You still need locks to protect your queue, but you don’t need to hold
them while you’re processing the I/O request.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hakim
Sent: Thursday, June 10, 2004 12:12 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeRaise\LowerIrql
ExAcquireFastMutex raises IRQL to APC_LEVEL. After acquring the mutex
some IoCallDriver is needed in my driver, but calling IoCallDriver by
holding any lock will be caught by driver verifier saying IRQL is not
same before and after IoCalldriver. I know from varous pundits that
IoCallDriver must not be used while holding a spin lock, yet it seems
that driver verifier forces it for any lock. Anyway, I need to use
IoCallDriver while holding the mutex, so to cheat driver verifier I
lower the IRQL to PASSIVE_LEVEL then do my IoCallDriver stuff and then
raise IRQL back to APC_LEVEL for releasing the mutex. It seems pretty
well cheating driver verifier. I don’t want to invent my own locking
mechanism, could anybody shed some light on to this matter?
For example, after lowering the irql if another thread tries to acquire
that mutex what will happen specially with SMP machine? To handle this
scenario what should be the safe way?