MMProbeAndLock in FS Filter

NTFSD
1

I am doing some maintenance work on an older FS filter driver (not a mini-filter). It’s function is to delay certain asynchronous FS Read and Write calls till it is appropriate to process them. It puts the IRP on a queue and then pends the IRP. Later, a worker thread sends the IRP on down to the File System.

The filter currently does a MMProbeAndLock on the users buffer before queueing and pending the IRP. This only happens if mdl address in the IRP is null. This is done because the IRP will be sent down the stack in the worker thread, not the original user thread.

I have read some things on this forum that would seem to indicate that this is unnecessary because the IO Manager will lock the buffer before it ever gets to me. But I have seen other information that says otherwise.

I am trying to determine if it is actually necessary to do the probe and lock. I would appreciate any input on this.

Thanks

Don

2

So far I know if device has set flag DO_DIRECT_IO the I/O manager does job for you. Including MMProbeAndLock() call. But to be honest you cannot rely on that. There are buggy filters which don’t delegate flags DO_DIRECT_IO & DO_BUFFERED_IO correctly. There are I/O which are not generated by I/O manager. So if MDLAddress is NULL and UserBuffer length is > 0 and you want to pend, you should both allocate and probe for proper access.

I was wrong in that the IRP flag should be set in different thread. I was mistaken by buffered operation.

Bronislav Gabrhelik