Ok, I think I may have an idea as to what the problem is.
The key is here:
[1]06E8.16F8::05/02/2015-14:29:17.681 [covefs3] Irp->ApcEnvironment: 0, Irp->Flags: 0x0
[1]06E8.16F8::05/02/2015-14:29:17.681 [covefs3] CurrentProcessId: 0x00000000000006E8, RequestorProcessId: 0x0000000000000004
[1]06E8.16F8::05/02/2015-14:29:17.681 [covefs3] CurrentThread: 0xFFFFFA8018535B50, IrpThread: 0xFFFFFA800CEB9B50
The current thread is different that the IRP thread. The current thread is the thread that is making the call into the file system, and the IRP thread is the user mode thread that actually made the request. How could these be different? Well, if a file system filter above us spawned another thread and is handling the request in that thread, while the original thread is told to wait, then that's exactly what you would see.
It really sounds to me like some other driver / FS filter is proxying the lock request for the caller above CoveFS.
In CoveFS we then we create our own IRPs to send down to the file system, their requestor thread is set to the current thread that we're in (makes sense since we're making the request from the current thread, and we're the requestor).
The problem occurs when a file lock operation is attempted on our proxy IRP. The file system (NTFS) needs to determine who to grant the exclusive file lock to (which thread?), so it asks the OS, who created the current IRP... and the OS comes back with the current thread that CoveFS was running on at the time. But, that's not the original caller's thread! It's the thread that was spawned above CoveFS, in the file system filter or some other driver. So the lock is granted to that thread. A subsequent read operation then occurs, and the filter chooses not to do the same proxying, or perhaps it uses an entirely different thread, and BAM, the read is failed because it's locked to a "different" thread.
"A driver might call IoBuildAsynchronousFsdRequest in one thread, and send the IRP allocated by this call in another thread. Before sending the IRP, this driver should set the Tail.Overlay.Thread member of the IRP to point to the thread object for the sending thread."
So that's what I'm doing now, and hopefully that will resolve this issue. This fix may affect other I/O operations as well when file system filters are involved.
* [D] [Issue #15581] Use the requestor thread context when forwarding I/O requests.