File System Behavior PDF seems inconsistent about oplock breaks

Hi all.

File System Behavior Overview - PDF from Microsoft
http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/file%20system%20behavior%20overview.pdf

The documentation contains tables that summarizes the conditions in which oplocks are broken. Everything was going fine until I reached “2.3.2 - IRP_MJ_READ”, which is supposed to list the conditions a given oplock would be broken when processing IRP_MJ_READ. However, the first line of this table seems inconsistent for me when it mentions about Level 1 and Batch oplock, saying:

Broken on IRP_MJ_READ when:

  • The read operation occurs on a FILE_OBJECT with a different oplock key from the FILE_OBJECT which owns the oplock.

The question is: How can a IRP_MJ_READ request occur on a different oplock key if an exclusive oplock would break when a IRP_MJ_CREATE happens to get a different oplock key?

From my understanding, the oplock is not broken on IRP_MJ_READ, but on IRP_MJ_CREATE.

What am I missing?

Thanks in advance.

A Level 1 (i.e. Exclusive) oplock won’t break on IRP_MJ_CREATE if there is no data access requested. It’s possible for a driver to use the resulting File Object for I/O anyway, so that could cause an IRP_MJ_READ to arrive without the break on create.

Now, I’m not sure if that’s the exact or only case this is handling. Usually you just let FsRtlCheckOplock take care of these annoying details for you.

1 Like

Oh… That’s a good point of view.

I was too focused on user-mode point of view and assuming a driver doing such a thing would be “breaking the rules”, but it is perfectly possible.

I’m creating a test application for oplock implementation, that will be used on a layered file system we have over here. Now I’m assuming this test application must have a kernel component to create the scenario you described.

Does anyone know if the HLK test uses a kernel driver to test this?

Thanks for your help!

It’s common enough that everyone should assume you can get reads/writes on a File Object opened without data access. Some filters even try to “play nice” and set the ReadAccess/WriteAccess fields to TRUE before sending down the I/O, which can be a mess if you’re relying on these fields properly reflecting the open flags.

The oplock tests use a minifilter but I’m not entirely sure what it does. I wouldn’t be surprised if they catch this case (those tests are incredibly comprehensive).

1 Like

I just saw it on the Oplock Test page below:
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/3d717052-7804-4de7-b097-a5e30b6bb7e5

There is an Opkey.sys on the list of files used on this test.

Many thanks!