Antwort: KeRaise\LowerIrql

Have a look at KeEnterCriticalRegion + ExAcquireFastMutexUnsafe.
That should disalbe APCs while keeping IRQL down at PASSIVE_LEVEL.

At least that’s how I interpret the DDK docs.
And of course you need to unlock it by calling ExReleaseFastMutexUnsafe +
KeLeaveCriticalRegion.

Regards,

Paul Groke

“Hakim”
Gesendet von: xxxxx@lists.osr.com
10.06.2004 21:11
Bitte antworten an “Windows System Software Devs Interest List”

An: “Windows System Software Devs Interest List”

Kopie:
Thema: [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

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

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

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

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

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
>

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

By ‘talking to another driver’ you mean sending an IRP to a device object,
or using a device interface controlled procedural interface? Then just let
pnp do its thing and you don’t release your reference to the device object
or the interface until you have finished with this transaction. There is no
need to hold any lock while doing this.

If your concern is the device object on which the create is being performed

  • it isn’t going away until at least after you have finished with this
    create operation.

=====================
Mark Roddy

-----Original Message-----
From: Hakim [mailto:xxxxx@yahoo.ca]
Sent: Thursday, June 10, 2004 4: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@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Well, then it seems that queueing create IRP is the easiest way to go as
well as a new varaible for this new state that will be protected using the
same spin lock as the create queue. So, now PnP state will also now be
protected by this spin lock instead of a mutex.
Am I going right?

Thanks,
Hakim

“Doron Holan” wrote in message
news:xxxxx@ntdev…
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

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.

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.


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

[To Mark: talking to another driver is by IRP, thanks for your hints.]

Further testing shows that I don’t need to queue my IRP rather make another
state variable as DeviceOpenPending (protected by the same mutex for PnP
state lock) and oring it with DeviceOpen for all PnP state comparison.

Thanks,
Hakim

“Hakim” wrote in message news:xxxxx@ntdev…
> Well, then it seems that queueing create IRP is the easiest way to go as
> well as a new varaible for this new state that will be protected using the
> same spin lock as the create queue. So, now PnP state will also now be
> protected by this spin lock instead of a mutex.
> Am I going right?
>
> Thanks,
> Hakim
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> 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
>
>
>

> for any lock. Anyway, I need to use IoCallDriver while holding the mutex,

Sorry, redesign your code to avoid this.

You must not hold any locks while doing any calls out of your binary.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

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.