If I have an EvtIoInCallerContext function and need to to do some
cleanup after the request has been queued and that cleanup must be done
in the caller’s context, what is the best way to do that? Does a
request’s cleanup callback function get called in the caller’s context?
If not, what is the recommended way to handle this?
Beverly
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
So… Did I understand this right? Cleanup in KMDF is guaranteed under *any* circumstances to run in the context of the calling thread? If so, that’s quite a departure from WDM where there IS such a guarantee.
Peter
OSR
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it) *AND* during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are *not guaranteed a context*. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext routine so that before and after an ICOTL, a driver can be guaranteed of running in the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the InCallerContext routine. I thought I read in the docs a recommendation not to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it) *AND* during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are *not guaranteed a context*. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues. For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
?
Beverly
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
What do you need to be in the app’s context for, anyway? Use your
InCallerContext to do whatever you need to do so that you can do any
further access in an arbitrary context. For *most* cases, that’s alrea=
dy
done for you, as your IOCTL will be either METHOD_BUFFERED or
METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those c=
ases
are already accessible in an arbitrary context. If you are embedding
pointers to user buffers in your input structure, you should definitely=
be
doing METHOD_BUFFERED for the structure, so you don’t have to worry abo=
ut
probing and locking it, at least. If you are doing this, once you’ve
probed and locked the user buffers from the addresses embedded in your
struct, MmGetMdlVirtualAddress provides the system VA that is usable in=
an
arbitrary context.
As far as your original question (Does Unlock need to happen in the UM
app’s context?), I’m amazed at how equivocal Doron has been about it. =
The
answer is unequivocally NO. If you can’t unlock pages in an arbitrary
context, then there are dozens of drivers out there that shouldn’t work=
,
because it’s quite common to lock user buffers in an IOCTL handler and
unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But
aside from the empirical evidence, think through *how* you would write =
that
routine. There’s never a need to access any memory through the user’s =
VA,
all of the memory the Unlock routine needs to access is reachable throu=
gh
system VAs at the point of unlocking. Remember that the Unlock isn’t
actually touching the user buffer itself, it doesn’t even need to read =
it
in order to fault it into memory. It’s only using structures that desc=
ribe
the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
=
“Brown, Beverly” =
=
Sent by: =
To
bounce-255564-643 “Windows System Software Devs =
xxxxx@lists.osr.com Interest List” =
No Phone Info =
Available =
cc
=
Subj=
ect
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext=
AM question =
=
=
Please respond to =
“Windows System =
Software Devs =
Interest List” =
com> =
=
=
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext rou=
tine
so that before and after an ICOTL, a driver can be guaranteed of runnin=
g in
the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the
InCallerContext routine. I thought I read in the docs a recommendation =
not
to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you ar=
e
powered on. This can occur when you have idled out (if you enabled it)=
AND during an Sx transition where your device has powered off and the=
app
is still running.
You cannot prevent drivers from loading on top of you, but they have to=
respect the contract that your FDO dictates (so if that means IOCTLs ar=
e
not pended, then that must be respected). With that said, KMDF has cre=
ates
a model where InCallerContext is the spot where you are guaranteed cont=
ext
and that your actual EvtIoXxx routines are not guaranteed a context. =
One
improvement coming down the pipe for the KMDF verifier is to force the
context switch.
Do not make the assumption that your EvtIoXxx routines will occur in th=
e
context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the
process context so it’s not really a good test of whether it would work=
if
it wasn’t in the process context.
For now it seems that if I use a parallel default queue with
synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl=
routine will predictably be called in the context of the calling proces=
s
(provided no filters are above me in the stack). Is there any reason wh=
y
this assumption (based on observation) will ever be wrong? Is there a w=
ay I
can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure …=
. if
I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as
you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply th=
at
it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed a=
bove
my driver) that the entire processing of an IOCTL would take place in t=
he
context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in
IoInCallerContext. When my EvtIoDeviceControl routine is called, I have=
no
idea what the framework has done between incallercontext and this callb=
ack
executing. It may be running in a work item for all I know. I need to c=
all
MmUnlockPages on a user buffer that was locked in InCallerContext (plea=
se -
no lectures about using direct IO instead - I understand all of the iss=
ues.
For this particular implementation, this is really what is called for).=
Or
is it not necessary that MmUnlockPages be called in the context of the
user-mode process that owns the buffer described by the MDL? I always
assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? =
Not
even in WDM do you have a facility to move back into the calling proces=
s’s
context after you leave it. KMDF makes no guarantees about the context=
in
which a request’s cleanup routine is called. By knowing what you need =
to
cleanup in the caller’s context, I or somebody on the list might able t=
o
give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some clean=
up
after the request has been queued and that cleanup must be done in the
caller’s context, what is the best=A0way to do that? Does a request’s c=
leanup
callback function get called in the caller’s context? If not, what is t=
he
recommended way to handle this?=00
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
=
Doron Holan wrote:
…With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are *not guaranteed a context*. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
This point was not clear to me before today. It’s a good thing you
posted this.
I have one ioctl in which the caller passes me a user-mode event handle
and the address of a 4-byte shared memory buffer. After reading this
message, I have now rewritten this to be handled in InCallerContext
instead of EvtIoIoctl.
Ordinarily, I would use IoAllocateMdl / MmProbeAndLockPages /
MmGetSystemAddressForMdlSafe to process this pointer. It would be nice
to use WdfRequestProbeAndLockUserBufferForWrite, but docs say that it
should only be called with a buffer that came from
WdfRequestRetrieveUnsafeUserBuffer, and that the resulting WDFMEMORY
object will be freed with the request. I *assume* I can call
WdfObjectReference to prevent the automatic freeing, but is it safe to
call WdfRequestProbeEtc with a pointer that other than one from
…UnsafeUserBuffer? Again, I *assume* it is OK, but I’d like to avoid
nasty surprises.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I am using InCallerContext but I was concerned about the call to MmUnlockPages that happens at the end of the IOCTL.
Thanks for that description of how MmUnlockPages works. However, it sounds more like a description of MmUnmapLockedPages. I don’t have an issue with the unmapping of a system VA, it’s the unlocking of a user-mode buffer that I am not sure of. Wouldn’t it need to touch some data structure somewhere that informs the memory manager that those pages may now be swapped out for that process? Wouldn’t that require access to something process-specific?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to be in the app’s context for, anyway? Use your InCallerContext to do whatever you need to do so that you can do any further access in an arbitrary context. For *most* cases, that’s already done for you, as your IOCTL will be either METHOD_BUFFERED or METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those cases are already accessible in an arbitrary context. If you are embedding pointers to user buffers in your input structure, you should definitely be doing METHOD_BUFFERED for the structure, so you don’t have to worry about probing and locking it, at least. If you are doing this, once you’ve probed and locked the user buffers from the addresses embedded in your struct, MmGetMdlVirtualAddress provides the system VA that is usable in an arbitrary context.
As far as your original question (Does Unlock need to happen in the UM app’s context?), I’m amazed at how equivocal Doron has been about it. The answer is unequivocally NO. If you can’t unlock pages in an arbitrary context, then there are dozens of drivers out there that shouldn’t work, because it’s quite common to lock user buffers in an IOCTL handler and unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But aside from the empirical evidence, think through *how* you would write that routine. There’s never a need to access any memory through the user’s VA, all of the memory the Unlock routine needs to access is reachable through system VAs at the point of unlocking. Remember that the Unlock isn’t actually touching the user buffer itself, it doesn’t even need to read it in order to fault it into memory. It’s only using structures that describe the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255564-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext routine so that before and after an ICOTL, a driver can be guaranteed of running in the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the InCallerContext routine. I thought I read in the docs a recommendation not to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it)
AND during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are not guaranteed a context. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues.
For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I would call that more of a description of how I think MmUnlockPages()
would work if I wrote it. 
Here’s more of how I would do it if I were writing it: The memory that=
would get updated to allow the pages to be evicted from physical memory=
is
the page table entry or the page descriptor, I can’t remember which rig=
ht
now, that has the pageable bit in it. I’ll leave it to someone with so=
urce
access to confirm or deny that particular detail.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
=
“Brown, Beverly” =
=
Sent by: =
To
bounce-255571-643 “Windows System Software Devs =
xxxxx@lists.osr.com Interest List” =
No Phone Info =
Available =
cc
=
Subj=
ect
07/05/2006 11:38 RE: [ntdev] KMDF InCallerContext=
AM question =
=
=
Please respond to =
“Windows System =
Software Devs =
Interest List” =
com> =
=
=
I am using InCallerContext but I was concerned about the call to
MmUnlockPages that happens at the end of the IOCTL.
Thanks for that description of how MmUnlockPages works. However, it sou=
nds
more like a description of MmUnmapLockedPages. I don’t have an issue wi=
th
the unmapping of a system VA, it’s the unlocking of a user-mode buffer =
that
I am not sure of. Wouldn’t it need to touch some data structure somewhe=
re
that informs the memory manager that those pages may now be swapped out=
for
that process? Wouldn’t that require access to something process-specifi=
c?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to be in the app’s context for, anyway? Use your
InCallerContext to do whatever you need to do so that you can do any
further access in an arbitrary context. For most cases, that’s alrea=
dy
done for you, as your IOCTL will be either METHOD_BUFFERED or
METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those c=
ases
are already accessible in an arbitrary context. If you are embedding
pointers to user buffers in your input structure, you should definitely=
be
doing METHOD_BUFFERED for the structure, so you don’t have to worry abo=
ut
probing and locking it, at least. If you are doing this, once you’ve
probed and locked the user buffers from the addresses embedded in your
struct, MmGetMdlVirtualAddress provides the system VA that is usable in=
an
arbitrary context.
As far as your original question (Does Unlock need to happen in the UM
app’s context?), I’m amazed at how equivocal Doron has been about it. =
The
answer is unequivocally NO. If you can’t unlock pages in an arbitrary
context, then there are dozens of drivers out there that shouldn’t work=
,
because it’s quite common to lock user buffers in an IOCTL handler and
unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But
aside from the empirical evidence, think through how you would write =
that
routine. There’s never a need to access any memory through the user’s =
VA,
all of the memory the Unlock routine needs to access is reachable throu=
gh
system VAs at the point of unlocking. Remember that the Unlock isn’t
actually touching the user buffer itself, it doesn’t even need to read =
it
in order to fault it into memory. It’s only using structures that desc=
ribe
the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: =
To
bounce-255564-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available =
cc
Subj=
ect
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext=
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext rou=
tine
so that before and after an ICOTL, a driver can be guaranteed of runnin=
g in
the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the
InCallerContext routine. I thought I read in the docs a recommendation =
not
to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you ar=
e
powered on. This can occur when you have idled out (if you enabled it)=
AND during an Sx transition where your device has powered off and the=
app
is still running.
You cannot prevent drivers from loading on top of you, but they have to=
respect the contract that your FDO dictates (so if that means IOCTLs ar=
e
not pended, then that must be respected). With that said, KMDF has cre=
ates
a model where InCallerContext is the spot where you are guaranteed cont=
ext
and that your actual EvtIoXxx routines are not guaranteed a context. =
One
improvement coming down the pipe for the KMDF verifier is to force the
context switch.
Do not make the assumption that your EvtIoXxx routines will occur in th=
e
context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the
process context so it’s not really a good test of whether it would work=
if
it wasn’t in the process context.
For now it seems that if I use a parallel default queue with
synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl=
routine will predictably be called in the context of the calling proces=
s
(provided no filters are above me in the stack). Is there any reason wh=
y
this assumption (based on observation) will ever be wrong? Is there a w=
ay I
can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure …=
. if
I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as
you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply th=
at
it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed a=
bove
my driver) that the entire processing of an IOCTL would take place in t=
he
context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in
IoInCallerContext. When my EvtIoDeviceControl routine is called, I have=
no
idea what the framework has done between incallercontext and this callb=
ack
executing. It may be running in a work item for all I know. I need to c=
all
MmUnlockPages on a user buffer that was locked in InCallerContext (plea=
se -
no lectures about using direct IO instead - I understand all of the iss=
ues.
For this particular implementation, this is really what is called for).=
Or
is it not necessary that MmUnlockPages be called in the context of the
user-mode process that owns the buffer described by the MDL? I always
assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? =
Not
even in WDM do you have a facility to move back into the calling proces=
s’s
context after you leave it. KMDF makes no guarantees about the context=
in
which a request’s cleanup routine is called. By knowing what you need =
to
cleanup in the caller’s context, I or somebody on the list might able t=
o
give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some clean=
up
after the request has been queued and that cleanup must be done in the
caller’s context, what is the best=A0way to do that? Does a request’s c=
leanup
callback function get called in the caller’s context? If not, what is t=
he
recommended way to handle this?
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=3D256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
=
Yes, but do those PTEs (or page descriptors) need to be accessed in the context of the process that owns the pages?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:59 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I would call that more of a description of how I think MmUnlockPages() would work if I wrote it.
Here’s more of how I would do it if I were writing it: The memory that would get updated to allow the pages to be evicted from physical memory is the page table entry or the page descriptor, I can’t remember which right now, that has the pageable bit in it. I’ll leave it to someone with source access to confirm or deny that particular detail.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255571-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 11:38 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
I am using InCallerContext but I was concerned about the call to MmUnlockPages that happens at the end of the IOCTL.
Thanks for that description of how MmUnlockPages works. However, it sounds more like a description of MmUnmapLockedPages. I don’t have an issue with the unmapping of a system VA, it’s the unlocking of a user-mode buffer that I am not sure of. Wouldn’t it need to touch some data structure somewhere that informs the memory manager that those pages may now be swapped out for that process? Wouldn’t that require access to something process-specific?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to be in the app’s context for, anyway? Use your InCallerContext to do whatever you need to do so that you can do any further access in an arbitrary context. For most cases, that’s already done for you, as your IOCTL will be either METHOD_BUFFERED or METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those cases are already accessible in an arbitrary context. If you are embedding pointers to user buffers in your input structure, you should definitely be doing METHOD_BUFFERED for the structure, so you don’t have to worry about probing and locking it, at least. If you are doing this, once you’ve probed and locked the user buffers from the addresses embedded in your struct, MmGetMdlVirtualAddress provides the system VA that is usable in an arbitrary context.
As far as your original question (Does Unlock need to happen in the UM app’s context?), I’m amazed at how equivocal Doron has been about it. The answer is unequivocally NO. If you can’t unlock pages in an arbitrary context, then there are dozens of drivers out there that shouldn’t work, because it’s quite common to lock user buffers in an IOCTL handler and unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But aside from the empirical evidence, think through how you would write that routine. There’s never a need to access any memory through the user’s VA, all of the memory the Unlock routine needs to access is reachable through system VAs at the point of unlocking. Remember that the Unlock isn’t actually touching the user buffer itself, it doesn’t even need to read it in order to fault it into memory. It’s only using structures that describe the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255564-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext routine so that before and after an ICOTL, a driver can be guaranteed of running in the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the InCallerContext routine. I thought I read in the docs a recommendation not to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it)
AND during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are not guaranteed a context. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues.
For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
No. Locking physical pages (which is what MmProbeAndLockPages & MmUnlockPages) operates on the system’s database of physical pages - in this case incrementing or decrementing the page’s “Lock Count”.
Until the lock count goes to zero the page won’t be written out or freed.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 10:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I am using InCallerContext but I was concerned about the call to MmUnlockPages that happens at the end of the IOCTL.
Thanks for that description of how MmUnlockPages works. However, it sounds more like a description of MmUnmapLockedPages. I don’t have an issue with the unmapping of a system VA, it’s the unlocking of a user-mode buffer that I am not sure of. Wouldn’t it need to touch some data structure somewhere that informs the memory manager that those pages may now be swapped out for that process? Wouldn’t that require access to something process-specific?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to be in the app’s context for, anyway? Use your InCallerContext to do whatever you need to do so that you can do any further access in an arbitrary context. For *most* cases, that’s already done for you, as your IOCTL will be either METHOD_BUFFERED or METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those cases are already accessible in an arbitrary context. If you are embedding pointers to user buffers in your input structure, you should definitely be doing METHOD_BUFFERED for the structure, so you don’t have to worry about probing and locking it, at least. If you are doing this, once you’ve probed and locked the user buffers from the addresses embedded in your struct, MmGetMdlVirtualAddress provides the system VA that is usable in an arbitrary context.
As far as your original question (Does Unlock need to happen in the UM app’s context?), I’m amazed at how equivocal Doron has been about it. The answer is unequivocally NO. If you can’t unlock pages in an arbitrary context, then there are dozens of drivers out there that shouldn’t work, because it’s quite common to lock user buffers in an IOCTL handler and unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But aside from the empirical evidence, think through *how* you would write that routine. There’s never a need to access any memory through the user’s VA, all of the memory the Unlock routine needs to access is reachable through system VAs at the point of unlocking. Remember that the Unlock isn’t actually touching the user buffer itself, it doesn’t even need to read it in order to fault it into memory. It’s only using structures that describe the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255564-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext routine so that before and after an ICOTL, a driver can be guaranteed of running in the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the InCallerContext routine. I thought I read in the docs a recommendation not to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it)
AND during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are not guaranteed a context. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues.
For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
This is all described fairly well in the latest version of Inside Windows NT (which I believe is now called “Windows Internals”).
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 10:59 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I would call that more of a description of how I think MmUnlockPages() would work if I wrote it.
Here’s more of how I would do it if I were writing it: The memory that would get updated to allow the pages to be evicted from physical memory is the page table entry or the page descriptor, I can’t remember which right now, that has the pageable bit in it. I’ll leave it to someone with source access to confirm or deny that particular detail.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255571-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 11:38 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
I am using InCallerContext but I was concerned about the call to MmUnlockPages that happens at the end of the IOCTL.
Thanks for that description of how MmUnlockPages works. However, it sounds more like a description of MmUnmapLockedPages. I don’t have an issue with the unmapping of a system VA, it’s the unlocking of a user-mode buffer that I am not sure of. Wouldn’t it need to touch some data structure somewhere that informs the memory manager that those pages may now be swapped out for that process? Wouldn’t that require access to something process-specific?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to be in the app’s context for, anyway? Use your InCallerContext to do whatever you need to do so that you can do any further access in an arbitrary context. For most cases, that’s already done for you, as your IOCTL will be either METHOD_BUFFERED or METHOD_IN/OUT_DIRECT, and the user buffer addresses provided in those cases are already accessible in an arbitrary context. If you are embedding pointers to user buffers in your input structure, you should definitely be doing METHOD_BUFFERED for the structure, so you don’t have to worry about probing and locking it, at least. If you are doing this, once you’ve probed and locked the user buffers from the addresses embedded in your struct, MmGetMdlVirtualAddress provides the system VA that is usable in an arbitrary context.
As far as your original question (Does Unlock need to happen in the UM app’s context?), I’m amazed at how equivocal Doron has been about it. The answer is unequivocally NO. If you can’t unlock pages in an arbitrary context, then there are dozens of drivers out there that shouldn’t work, because it’s quite common to lock user buffers in an IOCTL handler and unlock them in a DPC. (IF you MUST lock a user buffer, that is.) But aside from the empirical evidence, think through how you would write that routine. There’s never a need to access any memory through the user’s VA, all of the memory the Unlock routine needs to access is reachable through system VAs at the point of unlocking. Remember that the Unlock isn’t actually touching the user buffer itself, it doesn’t even need to read it in order to fault it into memory. It’s only using structures that describe the memory buffer, and those are all accessed through system VAs.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Brown, Beverly”
Sent by: To
bounce-255564-643 “Windows System Software Devs
xxxxx@lists.osr.com Interest List”
No Phone Info
Available cc
Subject
07/05/2006 10:27 RE: [ntdev] KMDF InCallerContext
AM question
Please respond to
“Windows System
Software Devs
Interest List”
com>
That has been my concern.
Can there be a PreInCallerContext routine and a PostInCallerContext routine so that before and after an ICOTL, a driver can be guaranteed of running in the caller’s context?
Short of that, I guess I’ll have to handle the entire request in the InCallerContext routine. I thought I read in the docs a recommendation not to do that though. I’ll have to re-read them.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, July 05, 2006 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
If you are powered off and the i/o arrives, it will pended until you are powered on. This can occur when you have idled out (if you enabled it)
AND during an Sx transition where your device has powered off and the app is still running.
You cannot prevent drivers from loading on top of you, but they have to respect the contract that your FDO dictates (so if that means IOCTLs are not pended, then that must be respected). With that said, KMDF has creates a model where InCallerContext is the spot where you are guaranteed context and that your actual EvtIoXxx routines are not guaranteed a context. One improvement coming down the pipe for the KMDF verifier is to force the context switch.
Do not make the assumption that your EvtIoXxx routines will occur in the context of the app.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, July 05, 2006 8:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
So far so good, but my IoDeviceControl routine is being called in the process context so it’s not really a good test of whether it would work if it wasn’t in the process context.
For now it seems that if I use a parallel default queue with synchronizationsocpenone and exectuionleveldispatch, my IoDeviceControl routine will predictably be called in the context of the calling process (provided no filters are above me in the stack). Is there any reason why this assumption (based on observation) will ever be wrong? Is there a way I can prevent other drivers from sitting above mine in the stack?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 8:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Let us know how it works after you try it. Like I said I’m not sure … if I’m wrong we should document that for the archives.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 4:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
That simplifies things a great deal! Thank you!
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, June 26, 2006 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
I believe that you can call MmUnlockPages from any context, as long as you’re at or below DISPATCH_LEVEL.
Not positive about that, but a quick look at the code seems to imply that it handles it okay.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 3:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
In WDM, I could be fairly certain (provided no filters were installed above my driver) that the entire processing of an IOCTL would take place in the context of the calling process. I had control over that.
With WDF, the only time I am certain that is the case is in IoInCallerContext. When my EvtIoDeviceControl routine is called, I have no idea what the framework has done between incallercontext and this callback executing. It may be running in a work item for all I know. I need to call MmUnlockPages on a user buffer that was locked in InCallerContext (please - no lectures about using direct IO instead - I understand all of the issues.
For this particular implementation, this is really what is called for). Or is it not necessary that MmUnlockPages be called in the context of the user-mode process that owns the buffer described by the MDL? I always assumed that it was, but maybe I have been overly cautious?
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 26, 2006 6:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
What do you need to cleanup that needs to be in the caller’s context? Not even in WDM do you have a facility to move back into the calling process’s context after you leave it. KMDF makes no guarantees about the context in which a request’s cleanup routine is called. By knowing what you need to cleanup in the caller’s context, I or somebody on the list might able to give a better answer to what you want to accomplish
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, June 26, 2006 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF InCallerContext question
If I have an EvtIoInCallerContext function and need to to do some cleanup after the request has been queued and that cleanup must be done in the caller’s context, what is the best?way to do that? Does a request’s cleanup callback function get called in the caller’s context? If not, what is the recommended way to handle this?
Beverly
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
You can call WdfRequestProbeAndLockUserBufferForWrite on any buffer you
choose, not just a buffer that comes from a retrieve unsafe buffer DDI.
You cannot use WdfObjectReference to keep the memory around longer then
the WDFREQUEST though. The WDFREQUEST tracks all WDFMEMORYs that have
been created via probe&lock and will bugcheck if any are still
outstanding when the request completes.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, July 05, 2006 10:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF InCallerContext question
Doron Holan wrote:
…With that said, KMDF has creates a model where InCallerContext is
the spot where you are guaranteed context and that your actual EvtIoXxx
routines are *not guaranteed a context*. One improvement coming down
the pipe for the KMDF verifier is to force the context switch.Do not make the assumption that your EvtIoXxx routines will occur in
the context of the app.
This point was not clear to me before today. It’s a good thing you
posted this.
I have one ioctl in which the caller passes me a user-mode event handle
and the address of a 4-byte shared memory buffer. After reading this
message, I have now rewritten this to be handled in InCallerContext
instead of EvtIoIoctl.
Ordinarily, I would use IoAllocateMdl / MmProbeAndLockPages /
MmGetSystemAddressForMdlSafe to process this pointer. It would be nice
to use WdfRequestProbeAndLockUserBufferForWrite, but docs say that it
should only be called with a buffer that came from
WdfRequestRetrieveUnsafeUserBuffer, and that the resulting WDFMEMORY
object will be freed with the request. I *assume* I can call
WdfObjectReference to prevent the automatic freeing, but is it safe to
call WdfRequestProbeEtc with a pointer that other than one from
…UnsafeUserBuffer? Again, I *assume* it is OK, but I’d like to avoid
nasty surprises.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hmm. We totally missed that little gem. Am I correct in my interpretation
of the WDFMEMORY and WdfMemoryGetBuffer usage that the WDFMEMORY is an
opaque handle to a struct that contains, among other things, an MDL?
Since I’m going to go through the trouble of moving the IoAllocateMdl() /
MmProbeAndLockPages() / MmGetSystemAddressForMdlSafe() calls to
EvtIoInCallerContext, I’m wondering if it’s worth the extra work to use the
WdfRequestProbeAndLockUserBufferForRead/Write and the associated WDFMEMORY
objects instead of using the MDL directly like we do now. Since I can’t
find a way to get the MDL from the WDFMEMORY object, and I need the MDL to
call BuildScatterGatherList(), I’m thinking maybe not.
On a related note, I see that *someone* used MmGetMdlVirtualAddress()
instead of MmGetSystemAddressForMdlSafe() to get the VA. If I’m reading
the docs correctly, and it’s certainly possible that I am not,
MmGetMdlVirtualAddress() returns the VA that is only valid in the process
context, (Inside the EvtIoInCallerContext() routine, then, would be the
only time I’m guaranteed that address is safe to use.) and
MmGetSystemAddressForMdlSafe() returns the VA that’s valid in any context.
So far, since we are only doing DMA, this appears to work, but do I
understand correctly that if I try to do PIO into or out of a VA obtained
with MmGetMdlVirtualAddress(), I will eventually end up in an arbitrary
context and bugcheck (or worse, corrupt memory)?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Doron Holan”
osoft.com> To
Sent by: “Windows System Software Devs
bounce-255582-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
RE: [ntdev] KMDF InCallerContext
07/05/2006 02:48 question
PM
Please respond to
“Windows System
Software Devs
Interest List”
com>
You can call WdfRequestProbeAndLockUserBufferForWrite on any buffer you
choose, not just a buffer that comes from a retrieve unsafe buffer DDI.
You cannot use WdfObjectReference to keep the memory around longer then
the WDFREQUEST though. The WDFREQUEST tracks all WDFMEMORYs that have
been created via probe&lock and will bugcheck if any are still
outstanding when the request completes.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, July 05, 2006 10:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF InCallerContext question
Doron Holan wrote:
>…With that said, KMDF has creates a model where InCallerContext is
the spot where you are guaranteed context and that your actual EvtIoXxx
routines are not guaranteed a context. One improvement coming down
the pipe for the KMDF verifier is to force the context switch.
>
>Do not make the assumption that your EvtIoXxx routines will occur in
the context of the app.
>
>
This point was not clear to me before today. It’s a good thing you
posted this.
I have one ioctl in which the caller passes me a user-mode event handle
and the address of a 4-byte shared memory buffer. After reading this
message, I have now rewritten this to be handled in InCallerContext
instead of EvtIoIoctl.
Ordinarily, I would use IoAllocateMdl / MmProbeAndLockPages /
MmGetSystemAddressForMdlSafe to process this pointer. It would be nice
to use WdfRequestProbeAndLockUserBufferForWrite, but docs say that it
should only be called with a buffer that came from
WdfRequestRetrieveUnsafeUserBuffer, and that the resulting WDFMEMORY
object will be freed with the request. I assume I can call
WdfObjectReference to prevent the automatic freeing, but is it safe to
call WdfRequestProbeEtc with a pointer that other than one from
…UnsafeUserBuffer? Again, I assume it is OK, but I’d like to avoid
nasty surprises.
Yes, the WDFMEMORY created by the call to
WdfRequestProbeAndLockUserBufferForRead/Write internally has a PMDL and
then probes and locks the pages. There is no way currently to get a
PMDL out of a WDFMEMORY, we could not come up with a clean model to
expose this (and we really wanted to expose it).
If you need the PMDL for your own DMA operations, then you need to
continue to what you are doing (or create another PMDL off of the system
VA that the WDFMEMORY gives you). KMDF does not call
MmGetMdlVirtualAddress() internally, IIRC, this will give you the UM VA
for the buffer (in this case).
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 05, 2006 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF InCallerContext question
Hmm. We totally missed that little gem. Am I correct in my
interpretation of the WDFMEMORY and WdfMemoryGetBuffer usage that the
WDFMEMORY is an opaque handle to a struct that contains, among other
things, an MDL?
Since I’m going to go through the trouble of moving the IoAllocateMdl()
/
MmProbeAndLockPages() / MmGetSystemAddressForMdlSafe() calls to
EvtIoInCallerContext, I’m wondering if it’s worth the extra work to use
the WdfRequestProbeAndLockUserBufferForRead/Write and the associated
WDFMEMORY objects instead of using the MDL directly like we do now.
Since I can’t find a way to get the MDL from the WDFMEMORY object, and I
need the MDL to call BuildScatterGatherList(), I’m thinking maybe not.
On a related note, I see that *someone* used MmGetMdlVirtualAddress()
instead of MmGetSystemAddressForMdlSafe() to get the VA. If I’m reading
the docs correctly, and it’s certainly possible that I am not,
MmGetMdlVirtualAddress() returns the VA that is only valid in the
process context, (Inside the EvtIoInCallerContext() routine, then, would
be the only time I’m guaranteed that address is safe to use.) and
MmGetSystemAddressForMdlSafe() returns the VA that’s valid in any
context.
So far, since we are only doing DMA, this appears to work, but do I
understand correctly that if I try to do PIO into or out of a VA
obtained with MmGetMdlVirtualAddress(), I will eventually end up in an
arbitrary context and bugcheck (or worse, corrupt memory)?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Doron Holan”
osoft.com>
To
Sent by: “Windows System Software Devs
bounce-255582-643 Interest List”
xxxxx@lists.osr.com
No Phone Info
cc
Available
Subject
RE: [ntdev] KMDF InCallerContext
07/05/2006 02:48 question
PM
Please respond to
“Windows System
Software Devs
Interest List”
com>
You can call WdfRequestProbeAndLockUserBufferForWrite on any buffer you
choose, not just a buffer that comes from a retrieve unsafe buffer DDI.
You cannot use WdfObjectReference to keep the memory around longer then
the WDFREQUEST though. The WDFREQUEST tracks all WDFMEMORYs that have
been created via probe&lock and will bugcheck if any are still
outstanding when the request completes.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, July 05, 2006 10:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF InCallerContext question
Doron Holan wrote:
>…With that said, KMDF has creates a model where InCallerContext is
the spot where you are guaranteed context and that your actual EvtIoXxx
routines are not guaranteed a context. One improvement coming down
the pipe for the KMDF verifier is to force the context switch.
>
>Do not make the assumption that your EvtIoXxx routines will occur in
the context of the app.
>
>
This point was not clear to me before today. It’s a good thing you
posted this.
I have one ioctl in which the caller passes me a user-mode event handle
and the address of a 4-byte shared memory buffer. After reading this
message, I have now rewritten this to be handled in InCallerContext
instead of EvtIoIoctl.
Ordinarily, I would use IoAllocateMdl / MmProbeAndLockPages /
MmGetSystemAddressForMdlSafe to process this pointer. It would be nice
to use WdfRequestProbeAndLockUserBufferForWrite, but docs say that it
should only be called with a buffer that came from
WdfRequestRetrieveUnsafeUserBuffer, and that the resulting WDFMEMORY
object will be freed with the request. I assume I can call
WdfObjectReference to prevent the automatic freeing, but is it safe to
call WdfRequestProbeEtc with a pointer that other than one from
…UnsafeUserBuffer? Again, I assume it is OK, but I’d like to avoid
nasty surprises.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer