Looks like serious oplock bug in CSV FS

NTFSD
1

Hello CSV team,

I have found critical (for me) bug in CSV file system. I am trying to make CSV aware minifilter and to use oplocks

for memory mapped file internodes - synchronization to ensure that data will be consistent in any case.

And I have found reproducible case when CSV FS returns STATUS_OPLOCK_NOT_GRANTED for oplock IOCL request with no reason. I think that is connected somehow with memory mapped files internals because I do not observe such behaviour for “normal” files that are not memory mapped.

Here the steps:

  1. Open memory mapped file on Node1

  2. Get RW oplock on that file with appropriate IOCL

  3. Close file handle

  4. Open memory mapped file on Node2

  5. Ask for RW oplock on that file with appropriate IOCL. Here I failed to get oplock with STATUS_OPLOCK_NOT_GRANTED. BUT if I am restarting cluster service - I get it. AND even if I JUST RENAME that file let say from 1.btm to temp.btm and then rename back from temp.btm to 1.btm - the oplock will be granted. That is evidence that handle is not opened I the reason is not in my code.

I have checked this from kernel and from user mode(I have write simple C# test application where you can simply reproduce this).

Also, sometimes I, in oplock completion routine, got strange REQUEST_OPLOCK_OUTPUT_BUFFER.Flags value = 0xffffe000. What does this mean? there is no such REQUEST_OPLOCK_OUTPUT_FLAG_* value …

Any ideas how to workaround this? I can rename file each time but that looks too beautiful :slight_smile:

2

Just for those who will have same problems. That is not a bug, this is by design: MM/CC will establish caching on that file and will hold to that file object to back up the section. So RW oplock on other node can’t be granted until someone will make changes in file. So I am using follow woraround - I am reading and then rewriting the first byte of file to break oplock in MM on other node.