Mini-filter Communication Port / Thread-safe Concurrent Access

NTFSD
1

Microsoft's documentation doesn't make any statements about how concurrent use of a PFLT_PORT (client port) instance should be handled from kernel-mode code when FltSendMessage() is being called by multiple threads at the same time for the same PFLT_PORT instance.

I've read at least one discussion on here about the user-mode side of things where a single call was made to FilterConnectCommunicationPort() and then simultaneous Filter*() function calls were made using a single handle value with improper & unexpected behavior occurring. The expectation is that when kernel-mode code calls FltCreateCommunicationsPort(), it should specify a 'MaxConnections' value greater than one and then the user-mode code should call FilterConnectCommunicationPort() up to 'MaxConnections' times to open multiple unique handles to the communication port for use by the user-mode code when making various Filter*() function calls where each concurrent Filter*() function call uses a unique handle.

Does anybody have a link to any reliable reference or actual experience with multiple threads making simultaneous calls to FltSendMessage() using the single PFLT_PORT instance obtained from a call to FltCreateCommunicationsPort()?

My expectation is that even if 'MaxConnections' had a value of one, the concurrent calls to FltSendMessage() would be serialized by the Filter Manager with only a single call to FltSendMessage() actually being processed while the others are blocked. For a 'MaxConnections' value greater than one, then the Filter Manager would allow concurrent processing of simultaneous calls to FltSendMessage() up to however many actual client connections (handles) are connected to the port at the moment, with the remainder of the concurrent calls to FltSendMessage() being stalled/blocked. Given the lack of any documentation references about concurrency & thread-safety, this seems like the only way to have things behave in a consistent & rational manner.

2

I think I self-answered the question. I was mistakenly conflating the server-side PFLT_PORT created by calling FltCreateCommunicationPort() with the individual PFLT_PORT values that get created as user-mode code calls FilterConnectCommunicationPort() and the PFLT_CONNECT_NOTIFY callback is invoked to provide the PFLT_PORT value for the client-side port. These will be distinct PFLT_PORT values for each client connection that is made, and the driver must maintain a list of them as they are connected & disconnected. It is up to the driver code to to make concurrent calls to FltSendMessage() using the available PFLT_PORT instances that currently exist, including handling the situation where no instances exist.