Implementing XxxCsqInsertItp...

OSR_Community_User · October 27, 2004, 2:51pm

There is a condition in my driver where I want to make
sure no more IRPs are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp()
function rather than queuing it, or will that cause the
csq implementation heart burn?

Thanks,

Joseph

OSR_Community_User · October 27, 2004, 3:09pm

You want to cancel the irp from with the csq insert irp implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine, the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make
sure no more IRPs are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp()
function rather than queuing it, or will that cause the
csq implementation heart burn?

Thanks,

Joseph

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

OSR_Community_User · October 27, 2004, 3:53pm

Thank you. I knew there was a good reason to ask. Another
fine idea shot down by the hard cold reality of life

Back to the drawing board.

Thanks,

Joseph

Doron Holan wrote:

You want to cancel the irp from with the csq insert irp implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine, the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make
sure no more IRPs are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp()
function rather than queuing it, or will that cause the
csq implementation heart burn?

Thanks,

Joseph

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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 27, 2004, 4:42pm

In the insertion function, you can maintain state and reject the
insertion based on that. You can then propagate a status back up to the
caller of insert to do the purge for you. There is a ddk example,
startio (or cancelio, I can’t remember) which demonstrates who to create
a start io like queue with CSQ and one Boolean.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Wednesday, October 27, 2004 12:52 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing XxxCsqInsertItp…

Thank you. I knew there was a good reason to ask. Another
fine idea shot down by the hard cold reality of life

Back to the drawing board.

Thanks,

Joseph

Doron Holan wrote:

You want to cancel the irp from with the csq insert irp
implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine,
the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph
Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make
sure no more IRPs are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp()
function rather than queuing it, or will that cause the
csq implementation heart burn?

Thanks,

Joseph

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: unknown lmsubst tag
argument: ‘’
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

OSR_Community_User · October 27, 2004, 10:09pm

The way you can solve this is: Have an IoCsqInsertIrpEx() that fails
further insertion given a flag that is checked using the queue lock.
Essentially IoCsqInsertIrpEx() will accept a new insert method that
returns a status: when you are ready to stop queueing more, you acquire
the queue lock and set the flag. In your insert method, you acquire the
queue lock and if it is set, you will return a failure status (you can
complete the IRP here if you want). It will prevent further insertions.
Next you empty all IRPs from the csq list via IoCsqRemoveNextIrp() and
complete them. To re-enable the queue you will simply have to hold the
queue lock and set the flag again.
Unfortunately IoCsqInsertIrpEx() has not shipped in earlier versions.

But we did change the implementation - at least for XP SP2 (may have to
check how far back this went) that if you set DriverContext[3] to NULL
in your insert function, IoCsqInsertIrp() would abort the insertion. So
you can use this method to set DriverContext[3] to NULL, thereby letting
I/O abort the insertion, and you can set your insertion routine to
return a status to the caller to IoCsqInsertIrp() by setting the
variable that DriverContext[2] points to, to the failure status, when
your flag is set. The caller of IoCsqInsertIrp() would first set
DriverContext[2] to point to a local variable that contains the status,
so you can check that local variable after calling IoCsqInsertIrp() to
check if the insertion succeeded (as you can’t touch the IRP anymore).

The second paragraph depends on whether the DriverContext[3] hack made
it to the OS versions you are interested in. Maybe Doron can verify.

Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 27, 2004 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Implementing XxxCsqInsertItp…

You want to cancel the irp from with the csq insert irp implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine, the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make sure no more IRPs
are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp() function
rather than queuing it, or will that cause the csq implementation heart
burn?

Thanks,

Joseph

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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 29, 2004, 4:26pm

Thanks.

I didn’t know about the IoCsqInsertIrpEx() version; that is exactly
what I was looking for.

Unfortunately, I have to support versions back to 2000. The docs
say I can use csq.lib and get it though… is this true? It seems
like that would be a better solution thand the DriverContext[3]
hack.

Thanks again,

Joseph

Ravisankar Pudipeddi wrote:

The way you can solve this is: Have an IoCsqInsertIrpEx() that fails
further insertion given a flag that is checked using the queue lock.
Essentially IoCsqInsertIrpEx() will accept a new insert method that
returns a status: when you are ready to stop queueing more, you acquire
the queue lock and set the flag. In your insert method, you acquire the
queue lock and if it is set, you will return a failure status (you can
complete the IRP here if you want). It will prevent further insertions.
Next you empty all IRPs from the csq list via IoCsqRemoveNextIrp() and
complete them. To re-enable the queue you will simply have to hold the
queue lock and set the flag again.
Unfortunately IoCsqInsertIrpEx() has not shipped in earlier versions.

But we did change the implementation - at least for XP SP2 (may have to
check how far back this went) that if you set DriverContext[3] to NULL
in your insert function, IoCsqInsertIrp() would abort the insertion. So
you can use this method to set DriverContext[3] to NULL, thereby letting
I/O abort the insertion, and you can set your insertion routine to
return a status to the caller to IoCsqInsertIrp() by setting the
variable that DriverContext[2] points to, to the failure status, when
your flag is set. The caller of IoCsqInsertIrp() would first set
DriverContext[2] to point to a local variable that contains the status,
so you can check that local variable after calling IoCsqInsertIrp() to
check if the insertion succeeded (as you can’t touch the IRP anymore).

The second paragraph depends on whether the DriverContext[3] hack made
it to the OS versions you are interested in. Maybe Doron can verify.

Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 27, 2004 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Implementing XxxCsqInsertItp…

You want to cancel the irp from with the csq insert irp implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine, the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make sure no more IRPs
are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp() function
rather than queuing it, or will that cause the csq implementation heart
burn?

Thanks,

Joseph

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: unknown lmsubst tag argument:
‘’
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 29, 2004, 4:35pm

If you use the latest DDK, then you will get the latest IOCSQ which
should be backwards compatible.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Friday, October 29, 2004 1:25 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Implementing XxxCsqInsertItp…

Thanks.

I didn’t know about the IoCsqInsertIrpEx() version; that is exactly
what I was looking for.

Unfortunately, I have to support versions back to 2000. The docs
say I can use csq.lib and get it though… is this true? It seems
like that would be a better solution thand the DriverContext[3]
hack.

Thanks again,

Joseph

Ravisankar Pudipeddi wrote:

The way you can solve this is: Have an IoCsqInsertIrpEx() that fails
further insertion given a flag that is checked using the queue lock.
Essentially IoCsqInsertIrpEx() will accept a new insert method that
returns a status: when you are ready to stop queueing more, you
acquire
the queue lock and set the flag. In your insert method, you acquire
the
queue lock and if it is set, you will return a failure status (you can
complete the IRP here if you want). It will prevent further
insertions.
Next you empty all IRPs from the csq list via IoCsqRemoveNextIrp() and
complete them. To re-enable the queue you will simply have to hold the
queue lock and set the flag again.
Unfortunately IoCsqInsertIrpEx() has not shipped in earlier versions.

But we did change the implementation - at least for XP SP2 (may have
to
check how far back this went) that if you set DriverContext[3] to NULL
in your insert function, IoCsqInsertIrp() would abort the insertion.
So
you can use this method to set DriverContext[3] to NULL, thereby
letting
I/O abort the insertion, and you can set your insertion routine to
return a status to the caller to IoCsqInsertIrp() by setting the
variable that DriverContext[2] points to, to the failure status, when
your flag is set. The caller of IoCsqInsertIrp() would first set
DriverContext[2] to point to a local variable that contains the
status,
so you can check that local variable after calling IoCsqInsertIrp() to
check if the insertion succeeded (as you can’t touch the IRP anymore).

The second paragraph depends on whether the DriverContext[3] hack made
it to the OS versions you are interested in. Maybe Doron can verify.

Ravi

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 27, 2004 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Implementing XxxCsqInsertItp…

You want to cancel the irp from with the csq insert irp
implementation?
That would be a bad idea. IoCancelIrp will call the cancel routine,
the
cancel routine will attempt to acquire the same lock that guards
insertion and you will deadlock.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph
Galbraith
Sent: Wednesday, October 27, 2004 11:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Implementing XxxCsqInsertItp…

There is a condition in my driver where I want to make sure no more
IRPs
are being queued.

Is it possible to simply cancel an IRP in my XxxCsqInsertIrp()
function
rather than queuing it, or will that cause the csq implementation
heart
burn?

Thanks,

Joseph

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: unknown lmsubst tag
argument:
‘’
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: unknown lmsubst tag
argument: ‘’
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