Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

venkat_narain · April 5, 2012, 7:22pm

hi,

I have a IOCTL that can accept requests with SEND_AND_FORGET flag set or completion routine set.

When the requested operation completes, I would like to see if the request was sent with SEND_AND_FORGET flag or not, before scheduling a workitem to complete the request.

Is there a way to get that information so as to decide whether or not queue up a work item?

thanks,
Venkat

Doron_Holan · April 5, 2012, 7:40pm

I don’t understand. You want to know if the driver that sent you the irp sent it as send and forget or it has its own completion routine? The answer is no, you can’t detect that. Why would you change your behavior if you could know?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, April 05, 2012 4:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

hi,

I have a IOCTL that can accept requests with SEND_AND_FORGET flag set or completion routine set.

When the requested operation completes, I would like to see if the request was sent with SEND_AND_FORGET flag or not, before scheduling a workitem to complete the request.

Is there a way to get that information so as to decide whether or not queue up a work item?

thanks,
Venkat

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

venkat_narain · April 5, 2012, 7:46pm

Thanks Doron. Basically I am completing the operation when my hw’s ISR/DPC gets invoked. So we schedule a workitem to complete the request (so that the completionroutine associated with the request won’t be running at < Dispatch). But setting up the workitem would probably be unnecessary if the client didnt care about the completion of this request. So wanted to see if I can avoid setting up a workitem and executing it, for requests that are flagged send_and_forget.

thanks,
Venkat

Doron_Holan · April 5, 2012, 7:48pm

Requests can be completed at dispatch_level. Instead of the driver who is completing the request forcing the IRQL back to passive level, the sender should do it if they care about a specific IRQL and queue their own work item in their completion routine

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, April 05, 2012 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

Thanks Doron. Basically I am completing the operation when my hw’s ISR/DPC gets invoked. So we schedule a workitem to complete the request (so that the completionroutine associated with the request won’t be running at < Dispatch). But setting up the workitem would probably be unnecessary if the client didnt care about the completion of this request. So wanted to see if I can avoid setting up a workitem and executing it, for requests that are flagged send_and_forget.

thanks,
Venkat

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

venkat_narain · April 5, 2012, 11:24pm

Thanks Doran. However it also helps me avoid possible deadlock situations arising due to the completion routines queuing more requests with my driver. is there a recommended and safe way to complete the requests from the InterruptDpc without potentially deadlocking?

Doron_Holan · April 5, 2012, 11:30pm

How is it deadlocking? The only way it can deadlock is if you complete the request while holding a lock and acquire that lock in your io handler when initially processing the request

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, April 05, 2012 8:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

Thanks Doran. However it also helps me avoid possible deadlock situations arising due to the completion routines queuing more requests with my driver. is there a recommended and safe way to complete the requests from the InterruptDpc without potentially deadlocking?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

venkat_narain · April 6, 2012, 1:31am

Basically, I am setting the synchronization scope of my self-managed WDFQueue to WdfSynchronizationScopeDevice. I believe WDF will acquire a lock using the parentObject. Please do correct me if I am wrong. So if I use WdfObjectAcquireLock(Device) where Device being my WDFdevice object in my InterruptDpc, and then complete the request holding it, won’t that cause a deadlock (if the completion routine submits a new request to my driver)?

thanks

Doron_Holan · April 6, 2012, 2:54am

I can never remember my sync scopes correctly, but if you want the DPC to be synchronized with the queue, set sync scope device on the WDFDEVICE and KMDF will do this for you and then you won’t deadlock. Otherwise if you are holding on to a lock yourself, do NOT complete the request with the lock held. Do whatever state management you need with the lock held, drop the lock and complete the request.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, April 05, 2012 10:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

Basically, I am setting the synchronization scope of my self-managed WDFQueue to WdfSynchronizationScopeDevice. I believe WDF will acquire a lock using the parentObject. Please do correct me if I am wrong. So if I use WdfObjectAcquireLock(Device) where Device being my WDFdevice object in my InterruptDpc, and then complete the request holding it, won’t that cause a deadlock (if the completion routine submits a new request to my driver)?

thanks

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

venkat_narain · April 6, 2012, 9:37am

If WDF is calling the Dpc in a locked context, will there be any reason for me to Acquire the same lock in my DPC? Currently I dont have Automatic Serialization set to true for my Dpc and instead I am acquiring the lock on the device to serialize my Dpc with the Queue. Looks like AutomaticSerialization would actually be doing the same thing as AcquireLock (+Sequencing the calls to Queue handlers and Dpc). Are there any caveats with it?

Peter_Viscarola_OSR · April 6, 2012, 10:12am

Correct.

Not really, no.

Peter
OSR

Tim_Roberts · April 6, 2012, 1:11pm

Doron Holan wrote:

I can never remember my sync scopes correctly,…

That’s one of the most discouraging sentences I’ve ever encountered
here. If the author himself cannot keep these straight, then there is
absolutely no hope for me…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim_Roberts · April 6, 2012, 1:11pm

xxxxx@yahoo.com wrote:

Thanks Doron. Basically I am completing the operation when my hw’s ISR/DPC gets invoked. So we schedule a workitem to complete the request (so that the completionroutine associated with the request won’t be running at < Dispatch). But setting up the workitem would probably be unnecessary if the client didnt care about the completion of this request. So wanted to see if I can avoid setting up a workitem and executing it, for requests that are flagged send_and_forget.

“Send_and_forget” is a clever name, but it’s possible to read too much
into it. It does not mean that “no one cares about this IRP”. It
merely means “this driver does not need to be called during the
completion chain”. You are still required to complete EVERY IRP that
you receive.

Doron’s message is an important one: if your driver has to change its
behavior because of this, then you have a design flaw.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Doron_Holan · April 6, 2012, 1:38pm

While I was heavily involved in almost all parts KMDF (at one point I had dev ownership of everything but queues and DMA), I never implemented any of the code around sync scope and execution levels. As such, it never really integrated itself into my mental model of KMDF. Since it is somewhat isolated to queues and DPCs, I was able to survive with that gap :).

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 06, 2012 10:11 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

Doron Holan wrote:

I can never remember my sync scopes correctly,…

That’s one of the most discouraging sentences I’ve ever encountered here. If the author himself cannot keep these straight, then there is absolutely no hope for me…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Gary_Little-3 · April 6, 2012, 2:43pm

Wait’ll the gray out numbers the colored hairs on your head ?. sheesh ? and then they fall out …

Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

On Apr 6, 2012, at 12:11 PM, Tim Roberts wrote:

Doron Holan wrote:
> I can never remember my sync scopes correctly,…

That’s one of the most discouraging sentences I’ve ever encountered
here. If the author himself cannot keep these straight, then there is
absolutely no hope for me…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · April 6, 2012, 2:52pm

Have you seen my hairline? Not much left to all out at this point and I have no idea what is gray or not, there is so little left

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gary Little
Sent: Friday, April 06, 2012 11:43 AM
To: Windows System Software Devs Interest List
Cc: Gary Little
Subject: Re: [ntdev] Detecting if a request is flagged as WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET

Wait’ll the gray out numbers the colored hairs on your head … sheesh … and then they fall out …

Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net mailto:xxxxx

On Apr 6, 2012, at 12:11 PM, Tim Roberts wrote:

Doron Holan wrote:

I can never remember my sync scopes correctly,…

That’s one of the most discouraging sentences I’ve ever encountered
here. If the author himself cannot keep these straight, then there is
absolutely no hope for me…

–
Tim Roberts, xxxxx@probo.com mailto:xxxxx
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>