So if you’re synchronizing extremely rare events (and therefore don’t
care about performance), is there anything wrong with using a named
MUTEX (again, assuming you don’t get pended and then continue to hold
the mutex (which would allow the possibility of a worker thread trying
to grab it and deadlocking))?
Mind you, I don’t particularly like this solution, and only use it out
of desparation.
I also don’t see how queuing solves this problem. At some point, the
IoCallDriver has to happen, and if the mutex (or whatever) isn’t held at
that time, what keeps the other driver from stomping on that call? I
suppose you could implement your own entire polled or signaled
synchronization mechanism separate from the OS and ensure no
deadlocks… but uck.
Which leads me back to “Is there any safe and sane way to synchronize
with the IRP handling of another driver that you can’t change”?
Doron Holan wrote:
The danger is lock reacquisition. Let’s say you hold the device pnp
lock when you pass down the create. The driver below you sends a query
interface irp to the top of the stack in response to the create. When
you process the QI, you grab the pnp lock and you try to reacquire the
lock and either bugcheck or deadlock depending on the lock type (or
succeed if it’s a MUTEX, but let’s not go through that one…). This is
basic reentrancy stuff. As soon as you relinquish control on any thread
to another component, you almost always have to assume that the same
thread can reenter your driver through any means.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Thursday, June 10, 2004 3:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KeRaise\LowerIrql
Other than the fact that the other driver might be expecting some
particular IRQL for its requests, or the possibility of deadlocks
(either of which could probably be eliminated by careful design and/or
inspection), what are the potential problems that could be caused by
doing this? Is the vulnerability limited to situations where the IRP
might be pended?
I’m mostly wondering if I need to start worrying about the
synchronization mechanism you and I came up with at WinHEC 2003 to keep
the keyboard side of i8042prt and our mouse filter driver from stomping
on each other (which was essentially to filter the keyboard and hold a
synchronization mutex when passing down the keyboard LED state, etc.,
IRPs).
Doron Holan wrote:
>Then you need to build into your state machine a pending state where
you
>started some action and when the action completes, you update the
state
>to the completed state. You should never hold a lock (KEVENT,
>SEMAPHORE, MUTEX, etc) while calling out of your driver, the IRQL
>checking / manipulation is just a side of the lock being used and not
>the real issue.
>
>d
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Hakim
>Sent: Thursday, June 10, 2004 1:28 PM
>To: Windows System Software Devs Interest List
>Subject: Re:[ntdev] KeRaise\LowerIrql
>
> My driver will not succeed create IRP unless some conditions are met;
>these
>conditions are acquired by talking to another driver so PnP state
needs
>to
>be locked until the status of open is decided.
>
>Thanks,
>Hakim
>
>“Roddy, Mark” wrote in message
>>news:xxxxx@ntdev…
>>
>>
>>>What exactly is your concern here?
>>>
>>>
>>>
>>>=====================
>>>Mark Roddy
>>>
>>>-----Original Message-----
>>>From: Hakim [mailto:xxxxx@yahoo.ca]
>>>Sent: Thursday, June 10, 2004 4:02 PM
>>>To: Windows System Software Devs Interest List
>>>Subject: Re:[ntdev] KeRaise\LowerIrql
>>>
>>>To lock the PnP state of the driver during create.
>>>
>>>Hakim
>>>
>>>“Peter Wieland” wrote in message
>>>news:xxxxx@ntdev…
>>>What are you protecting?
>>>
>>>-p
>>>
>>>-----Original Message-----
>>>From: xxxxx@lists.osr.com
>>>[mailto:xxxxx@lists.osr.com] On Behalf Of Hakim
>>>Sent: Thursday, June 10, 2004 12:41 PM
>>>To: Windows System Software Devs Interest List
>>>Subject: Re:[ntdev] KeRaise\LowerIrql
>>>
>>>The locking requirement is during the Create IRP, should I make queue
>>
>>for
>>
>>
>>>create IRP? I have queues for all IRP except create\close, in fact I
>>
>>never
>>
>>
>>>needed.
>>>
>>>Hakim
>>>
>>>“Peter Wieland” wrote in message
>>>news:xxxxx@ntdev…
>>>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?
>>>
>>>Thanks,
>>>Hakim
>>>
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>http://www.osronline.com/article.cfm?id=256
>>>
>>>You are currently subscribed to ntdev as:
>>
>>xxxxx@windows.microsoft.com
>>To
>>
>>
>>>unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>http://www.osronline.com/article.cfm?id=256
>>>
>>>You are currently subscribed to ntdev as:
>>
>>xxxxx@windows.microsoft.com
>>To
>>
>>
>>>unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>http://www.osronline.com/article.cfm?id=256
>>>
>>>You are currently subscribed to ntdev as: xxxxx@stratus.com To
>>>unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>
>>
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.