Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!newsfeed.lightning.net!feeder.qis.net!newsfeed.direct.ca!newshub1.home.com!news.home.com!Supernews60!supernews.com!news.he.net!newshub.cts.com!newsfeed.cts.com!cmkrnl!jeh
From: jeh@cmkrnl.com (Jamie Hanrahan)
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: Accessing user-buffers in dispatch routine at DISPATCH_LEVEL
Message-ID: <1997Dec30.092820.8377@cmkrnl>
Date: 30 Dec 97 09:28:20 PST
References: <34A8C0DD.682FD2DC@nomail.com>
Organization: Kernel Mode Systems, San Diego, CA
Lines: 63

In article <34A8C0DD.682FD2DC@nomail.com>, "L.P" <no_direct_reply@nomail.com> writes:
> I want to access a user buffer using its user-space virtual address to
> copy its content into a system-space memory pool within the driver's
> dispatch routine.  I know this has been discussed in the group already
> but I need to perform the copy in between locks since the system-space
> memory pool is a shared resource.  Locking will bring the IRQL to
> DISPATCH_LEVEL but I will still be under user-thread context (correct me
> if I'm wrong here).  

Since you're talking about spinlocks, no, you're not wrong here. 

> To be perfectly safe, here is what I'm planning to do  :
> 
> 1) MmCreateMDL() on the user-space virtual address => MDL updated
> 2) MmProbeAndLockPages() on the MDL (with try...except around it, of
> course)
> 3) Get spin lock => IRQL jumps at DISPATCH_LEVEL
> 4) MmMapLockedPages() to make sure the locked pages are "mapped-in"
> using the user-space virtual address.
> 5) Copy the user-space buffer into system-space memory => That's what I
> wanted to do!.
> 6) MmUnmapLockedPages() => counterpart of step 4
> 7) Relinquish spin lock => going back to PASSIVE_LEVEL
> 8) MmUnlockPages() => counterpart of step 2
> 
> n.b: I must use the user-buffer virtual address in my scheme so I
> intently avoid using METHOD_XXX_DIRECT for the ioctl.

a. You are working much too hard.  Why not use METHOD_XXX_DIRECT?  If 
you must use the process-space virtual address you can pick it up via 
MmGetMdlVirtualAddress on the resulting MDL.  

b. It is safer to NOT use the process-space virtual address, as it
could be unmapped (VirtualFree) by the process at any time (even
though you're still holding the MDL).  I suppose that's why you're
doing the MmMapLockedPages.  However the preferred method is to use
MmGetSystemAddressForMdl.  If the process later hands you a virtual
address that's somewhere within the locked buffer, it is trivial to
calculate the offset from the start of the buffer to that address, and
apply that offset to the result of MmGetSystemAddressForMdl. 

> 3. I could get a system-space address for the locked user-buffer but I
> read (in the Art Baker book) that this is not advisable as ALL caches
> from ALL processors are flushed when unlocking the memory.  

I'm not aware of this and can't find any evidence of it.  

But whether it's true or not, you're doing the same thing by calling
MmMapLockedPages, as MmGetSystemAddressForMdl is just a macro around
MmMapLockedPages.  (The only difference being that (1) MmGSAFMdl
forces the AddressSpace argument to KernelMode and (2) the result is
stored in the MDL and a flag set so that if you call MmGSAFMdl again
on the same MDL,it won't remap it yet again.)  Any cache flushing that
has to be done when creating or deleting process-space addresses also
has to be done for system-space addresses, so you might as well use
the easier interface, which is MmGSAFMdl.  

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
        Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055  
drivers, internals, networks, applications, and training for VMS and Windows NT
NT driver FAQ, links, and other information:  http://www.cmkrnl.com/

If you post a reply in news, please don't e-mail it too.