MiniFilter Hold Read and Write

NTFSD
1

Ive been hunting down a deadlock bug for a little bit, and thought I would try some of the brain trust in here.

I have a minifilter that is for 2k -> vista. In a nutshell, I am only paying primary attention to creates, reads, and writes (plus MDL/FIO). I catch the read requests in the PreOperation callback, check to make sure they are mine, and if they are, I check to see if I need to plant some data before the read actually goes out. I do not change filesizes, and simply replace data at the offset requested (if it needs to be done).

I hold the PreOP and do a FltSendMessage to my usermode to read the data from another container and place it in the file that is being read at that particular offset (if needed). Then once the usermode is done, it sends over a command which signals my KeWait in the kernel driver and it continues to process.

The operation is which the usermode never reads the file that is held, only writes into it.

Everything works like a champ if I remark out my “fstream writes” no locks, everything logs on both sides, everyone communicates, life is good.

But when I reenable the actual write itself, it will write out quite a few entries, but then deadlock. I checked my threads on the kernel side, and they are waiting for the client to clear their wait state (as they should be).

So my question here is… If you are holding a read call in preop, and a write comes up will that also be held? (I did watch to see if I was getting writes that got held up, but didnt see any as I debugged thru the requests in the kernel).

Now I have used the FltAllocateDeferredIoWorkItem/FltQueueDeferredIoWorkItem when !IRP_PAGING_IO and the top condition. And it does work, but if I have to go that route (which i have no issues with) What would be the best approach to be able to write data out when I am getting a Paging IO call?

I can catch the call now, and process it, but writing data in that event will lock me up (never BSOD, and windows is still completely usable just not that process/thread set).

I do not register the write Pre/post op since I do zero kernel write operations in my filter. Its more like a passive/aggressive driver in which it passively watches reads, holds when needed then the user mode gets aggressive with writing.

Any thoughts? Hopefully I was able to give enough of a description, but in any case if needed I’ll be happy to post some code as its always the next set of eyes that catches the unseeable bug.

2

Update.

I moved my writer into the kernel code that sends its writes down from that instance so I do not have recursion. I have it logging all my reads and type of read so I can see whats going on. It seems that in the event I am writing to a particular area I will get my normal fast IO read request (which I then trigger my write event) and then behind it I get a paging read request. Since I cannot defer it into as a work item I wind up deadlocking.

From what I can see I have the writing function that is not being called correctly without any overlap of calls such as multiple write function calls hitting the same areas, or at all. I use a logger to show me entry to the routine/exit routine with thread and other related info.

The data from the writer is accurate and the object placement is correct after a reboot/winhex comparison.

It seems that if a write went out, and a paging read came in at a close interval it will deadlock. Any thoughts?