Intercepting oplock requests in a minifilter

Hi folks,

I wonder whether anyone might be able to advise me on how I can go
about detecting oplock requests in my minifilter.

So far I have tried the following two approaches.

Firstly, in my pre-create handler I am checking :

Data->Iopb->Parameters.Create.Options & FILE_RESERVE_OPFILTER

as per the MSDN documentation on IRP_MJ_CREATE[1]. Note that I’m
building for an XP box, so FILE_OPEN_REQUIRING_OPLOCK which is
supported in Windows 7 and above isn’t immediately relevant.

Secondly, in my pre-fsctl handler I am checking for IRPs in which
Data->Iopb->Parameters.FileSystemControl.Common.FsControlCode is one
of FSCTL_REQUEST_FILTER_OPLOCK, FSCTL_REQUEST_BATCH_OPLOCK,
FSCTL_REQUEST_OPLOCK_LEVEL_1 or FSCTL_REQUEST_OPLOCK_LEVEL_2. For
these IRP, I then make a call to FltRequestOperationStatusCallback()
as per the WinDDK passthru sample.

To test this code I am using Excel to open a file on a CIFS network
share. Examination of the traffic on the wire using Wireshark shows
that the client PC is making oplock requests using the SMB Locking
AndX command, however my driver doesn’t detect these requests using
either of the mechanisms described above.

Is there another mechanism for oplock requests that I have missed out ?

Alternatively, is it possible that the CIFS filesystem driver is
making the oplock requests on behalf of the userspace code rather than
userspace making the requests itself (thereby bypassing my minifilter)
?

If anyone can shed any light on this subject I’d be most grateful.

Regards,
Tom

[1]. http://msdn.microsoft.com/en-us/library/ms795806.aspx

Tom Parkin
www.thhp.org.uk
The worst moment for the atheist is when he is really thankful and has
nobody to thank /Rossetti/

> Alternatively, is it possible that the CIFS filesystem driver is

making the oplock requests on behalf of the userspace code

I think that this is a normal thing about oplocks. They originate in SMB redir when SMB redir thinks it is a good idea.

Then they are sent to the server by SMB protocol, where SRV converts the SMB requests to the Windows FSD calls.

The filters on server should see these requests if attached between SRV and the FSD.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

2009/12/2 Maxim S. Shatskih :
>> Alternatively, is it possible that the CIFS filesystem driver is
>> making the oplock requests on behalf of the userspace code
>
> I think that this is a normal thing about oplocks. They originate in SMB redir when SMB redir thinks it is a good idea.
>

Hum, I was afraid of that.

I wonder, though, what logic determines “when SMB redir thinks it is a
good idea”. Observing the on-the-wire SMB traffic between the server
and client I see no oplock requests when I open e.g. .zip, .txt or
.jpeg files (with Explorer, Notepad and Fax/Picture viewer,
respectively). Yet when I open an .xls file with Excel I see a flood
of oplock requests. Two options come to mind: firstly that the
options passed to CreateFile() by Excel imply to the CIFS redirector
that an oplock is necessary; secondly that some kind of heuristic is
performed within the CIFS redirector on the basis of file type or
similar (yikes!).

In any case, it seems from what you say that I cannot gain knowledge
of the oplocks held on a file from my minifilter… ?

Thanks,
Tom

Tom Parkin
www.thhp.org.uk
The worst moment for the atheist is when he is really thankful and has
nobody to thank /Rossetti/

> of oplock requests. Two options come to mind: firstly that the

options passed to CreateFile() by Excel imply to the CIFS redirector
that an oplock is necessary

I think so.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Tom Parkin wrote:

I wonder, though, what logic determines “when SMB redir thinks it is a
good idea”. Observing the on-the-wire SMB traffic between the server
and client I see no oplock requests when I open e.g. .zip, .txt or
.jpeg files (with Explorer, Notepad and Fax/Picture viewer,
respectively). Yet when I open an .xls file with Excel I see a flood
of oplock requests.

An oplock request is actually embedded in the SMB create request, so you
don’t see any separate oplock request frames for the .zip, .txt, and
.jpeg files. Any stand-alone oplock frames you see will be oplock
breaks. Another confusing point in the SMB1 protocol is that byte-range
lock request/response packets are identical to oplock break packets.
When a batch oplock breaks, the client flows byte-range lock requests to
the server. What you’re probably seeing are byte-range locks, rather
than oplock requests, since Office uses byte-range locks.

In any case, it seems from what you say that I cannot gain knowledge
of the oplocks held on a file from my minifilter… ?

Maxim is correct about how oplocks factor in to the RDR/SRV interaction.
So yes, there is no way to know from a minifilter on the client what
oplocks are being used.

In fact, you’ll see that if you have an app that attempts to directly
request an oplock on a remote file server, RDR will fail the oplock request.


Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.