Hi guys,
Consider this scenario:
My filter (legacy) receives a read IRP. This IRP will not be passed down to FSD, but it will be pended. Then, in a system worker thread my filter will issue a set of read IRPs to perform the read that was originally requested. Then the original read IRP will be unpended and completed. This works, however, this breaks byte range locking, since FSD will deny reads comming from a system process on condition that user process has BRL held on file. So, a solution I’m thinking of would be to “precreate” IRPs that then will be issued in a worker thread in context of the thread in which I received the original IRP. This way BRL check will pick correct requestor process and will return correct result. This, however, is not bullet proof, since original IRP may have reached my driver not in context of the originating thread / process, but in context of a system thread, because filter above has also pended it.
Another solution would be to copy Tail.Overlay.Thread from the original IRP to IRPs I pass to FSD in my worker thread. Those IRPs are async IRPs, so (at least theoretically) completion shouldn’t be an issue. In fact, this works, but I’m pretty sure that this is bad.
I guess, I’m looking for a solution on how to “inherit” requestor process from one IRP in another, manually created in my driver?
Any advice on that?