Accessing output buffer in a completion routine

NTFSD
1

Hi all,

I have legacy FSFD, which sits above NPFS.
The NPFS device has DO_NEITHER_IO, according to DeviceTree.
So, on IRP_MJ_WRITE, I have the data readily available in UserBuffer because
I’m in the caller’s context.
However, when I want to obtain the data read by IRP_MJ_WRITE, I obviously
fail because the completion routine runs in an arbitrary process context.

What’s the correct way of handling this?

Thanks in advance,
Greg.

2

You’d usually probe and lock the users buffer in the pre-write Then grab a system address in post write and have a party on the data.

What has never been clear to me is whether you are allowed to set Data->Iopb->Parameters.Write.MdlAddress and if you do whether FltMgr will clean it up for you, or whether that is a read only parameter…

“Greg” wrote in message news:xxxxx@ntfsd…
Hi all,

I have legacy FSFD, which sits above NPFS.
The NPFS device has DO_NEITHER_IO, according to DeviceTree.
So, on IRP_MJ_WRITE, I have the data readily available in UserBuffer because I’m in the caller’s context.
However, when I want to obtain the data read by IRP_MJ_WRITE, I obviously fail because the completion routine runs in an arbitrary process context.

What’s the correct way of handling this?

Thanks in advance,
Greg.

3

Hi Rod,

Thanks for the help. I actually meant a legacy filter, not a minifilter, but
the solution would be the same.
We are experimenting with the IRP’s MDL at the moment.

G.

On Wed, Dec 22, 2010 at 6:17 PM, Rod Widdowson wrote:

> You?d usually probe and lock the users buffer in the pre-write Then
> grab a system address in post write and have a party on the data.
>
> What has never been clear to me is whether you are allowed to set
> Data->Iopb->Parameters.Write.MdlAddress and if you do whether FltMgr will
> clean it up for you, or whether that is a read only parameter…
>
> “Greg” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> I have legacy FSFD, which sits above NPFS.
> The NPFS device has DO_NEITHER_IO, according to DeviceTree.
> So, on IRP_MJ_WRITE, I have the data readily available in UserBuffer
> because I’m in the caller’s context.
> However, when I want to obtain the data read by IRP_MJ_WRITE, I obviously
> fail because the completion routine runs in an arbitrary process context.
>
> What’s the correct way of handling this?
>
> Thanks in advance,
> Greg.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

“What has never been clear to me is whether you are allowed to set Data->Iopb->Parameters.Write.MdlAddress and if you do whether FltMgr will clean it up for you, or whether that is a read only parameter…”

Yes, you can set the MdlAddress (provided you mark the callbackdata dirty afterwards). Fltmgr will clean up the MDL for you. You are guaranteed that the parameters you see in a postOp callback are the same as the parameters you saw in the preOp (so filters must remember any changes they made to the Iopb … I use the pre-to-post context for this) so in the postOp you’ll see the original MDL. You can still get to the MDL you’ve allocated by using FltGetSwappedBufferMdlAddress and you can prevent FltMgr from releasing the new MDL by calling FltRetainSwappedBufferMdlAddress.

Thanks,

Alex.