OPLOCK Handling Sample Code

Ashish_Goyal · November 13, 2009, 7:37am

Hi,
Is there any sample code on how to handle OPLOCKS in Lagacy Filter
Drivers. I found some postings and Articles on OSR but not sample code.

Thanks
Ash

OSR_Community_User · November 13, 2009, 1:02pm

I’m not aware of any such code. The difference between minifilters and legacy filters should be minimal with respect to oplocks.

I’m curious, what aspect of handling oplocks are you interested in ? What are you trying to do (or what would a sample that you would consider good do) ?

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

Ashish_Goyal · November 13, 2009, 2:16pm

Alex,
We have a customer which is still running Windows 2000 and using our
legacy filter driver. They are having problems with OPLOCKS as we are not
handling OPLOCKS properly. When we recieve IRP_MJ_CREATEWe do another
IRP_MJ_CREATE to read the attributes . We do not check for
STATUS_OPLOCK_BREAK_IN_PROGRESS for this second IRP_MJ_CREATE and does
QueryInformation. Searching the NTFSD list, I found that we should return
immediately when we get STATUS_OPLOCK_BREAK_IN_PROGRESS and then wait for
FSCTL_OPLOCK_BREAK_NOTIFY. Some of the questions which I have is:

When we get STATUS_OPLOCK_BREAK_IN_PROGRESS in IRP_MJ_CREATE then shall
we close the fileobject which we get for second IRP_MJ_CREATE and create new
fileobject to query attributes in FSCTL_OPLOCK_BREAK_NOTIFY.
Can we get complete filename in FSCTL_OPLOCK_BREAK_NOTIFY as in
IRP_MJ_CREATE.
If we decide to not allow user to open file then can we fail the request
in FSCTL_OPLOCK_BREAK_NOTIFY. In that case, what error we should return.
Shall we handle Pre or Post of FSCTL_OPLOCK_BREAK_NOTIFY . From MSDN,

When the FSCTL_OPLOCK_BREAK_NOTIFY call returns STATUS_SUCCESS, this
signifies one of the following:**

No oplock granted.
No oplock break was in progress at the time of the call.
Any oplock break that was in progress is now complete.

By Handling in post, we can be sure that oplock is complete.

Thanks
Ash

On Fri, Nov 13, 2009 at 11:32 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:

I?m not aware of any such code. The difference between minifilters and
legacy filters should be minimal with respect to oplocks.

I?m curious, what aspect of handling oplocks are you interested in ? What
are you trying to do (or what would a sample that you would consider good
do) ?

Regards,

Alex.

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

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Christian_Allred · November 13, 2009, 7:59pm

Ashish Goyal wrote:

QueryInformation. Searching the NTFSD list, I found that we should
return immediately when we get STATUS_OPLOCK_BREAK_IN_PROGRESS and then
wait for FSCTL_OPLOCK_BREAK_NOTIFY. Some of the questions which I have is:

STATUS_OPLOCK_BREAK_IN_PROGRESS is a success code you can only get if
the create had the FILE_COMPLETE_IF_OPLOCKED flag set. That flag is the
“do not deadlock me” flag, and means that if the create results in an
oplock break, the create should complete immediately with
STATUS_OPLOCK_BREAK_IN_PROGRESS rather than waiting for the oplock owner
to acknowledge the break. Anybody who sets that flag is saying that
they cannot be blocked in the create.

It sounds like if your create gets STATUS_OPLOCK_BREAK_IN_PROGRESS,
you’re sending your own create with all the same flags as were on the
create you received, correct?

When we get STATUS_OPLOCK_BREAK_IN_PROGRESS in IRP_MJ_CREATE then
shall we close the fileobject which we get for second
IRP_MJ_CREATE and create new fileobject to query attributes in
FSCTL_OPLOCK_BREAK_NOTIFY.

It isn’t guaranteed that the caller will send FSCTL_OPLOCK_BREAK_NOTIFY.
Although using that FSCTL is the normal way for somebody who used
FILE_COMPLETE_IF_OPLOCKED on their create and got back
STATUS_OPLOCK_BREAK_IN_PROGRESS to determine when the oplock break is
completed, the oplock protocol doesn’t strictly require it. Therefore
relying on getting FSCTL_OPLOCK_BREAK_NOTIFY won’t always work.

Can we get complete filename in FSCTL_OPLOCK_BREAK_NOTIFY as in
IRP_MJ_CREATE.

If we decide to not allow user to open file then can we fail the
request in FSCTL_OPLOCK_BREAK_NOTIFY. In that case, what error we should
return.

If I’m understanding the purpose of this behaviour of your filter
correctly (you decide whether to allow the open based on the results of
your QueryInformation call, yes?), you have to fail the create.
STATUS_OPLOCK_BREAK_IN_PROGRESS is a success code; the user already has
his handle. Trying to do something in a subsequent call would be too
late if your goal is to prevent certain opens.

See the IRP_MJ_CREATE documentation at
http://msdn.microsoft.com/en-us/library/ms795806.aspx under
IrpSp->Parameters.Create.Options. There’s a part about
FILE_COMPLETE_IF_OPLOCKED. Specifically there’s a bit that says that if
your filter can’t honour the FILE_COMPLETE_IF_OPLOCKED_FLAG, you should
fail the create with STATUS_SHARING_VIOLATION.

Please let me know if this helps.

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

Ashish_Goyal · November 15, 2009, 12:21pm

Thanks Chris…Your comments concreted my understanding on handling OPLOCKS.

As you mentioned that FSCTL_OPLOCK_BREAK_NOTIFY might not be send by all
applications (this was the reason I was looking for sample code), Can I
assume that Network Redirector on windows platform will always send that?

Thanks
Ashish
On Sat, Nov 14, 2009 at 6:28 AM, Christian Allred wrote:

> Ashish Goyal wrote:
>
>> QueryInformation. Searching the NTFSD list, I found that we should return
>> immediately when we get STATUS_OPLOCK_BREAK_IN_PROGRESS and then wait for
>> FSCTL_OPLOCK_BREAK_NOTIFY. Some of the questions which I have is:
>>
>
> STATUS_OPLOCK_BREAK_IN_PROGRESS is a success code you can only get if the
> create had the FILE_COMPLETE_IF_OPLOCKED flag set. That flag is the “do not
> deadlock me” flag, and means that if the create results in an oplock break,
> the create should complete immediately with STATUS_OPLOCK_BREAK_IN_PROGRESS
> rather than waiting for the oplock owner to acknowledge the break. Anybody
> who sets that flag is saying that they cannot be blocked in the create.
>
> It sounds like if your create gets STATUS_OPLOCK_BREAK_IN_PROGRESS, you’re
> sending your own create with all the same flags as were on the create you
> received, correct?
>
>
> 1) When we get STATUS_OPLOCK_BREAK_IN_PROGRESS in IRP_MJ_CREATE then shall
>> we close the fileobject which we get for second IRP_MJ_CREATE and create new
>> fileobject to query attributes in FSCTL_OPLOCK_BREAK_NOTIFY.
>>
>
> It isn’t guaranteed that the caller will send FSCTL_OPLOCK_BREAK_NOTIFY.
> Although using that FSCTL is the normal way for somebody who used
> FILE_COMPLETE_IF_OPLOCKED on their create and got back
> STATUS_OPLOCK_BREAK_IN_PROGRESS to determine when the oplock break is
> completed, the oplock protocol doesn’t strictly require it. Therefore
> relying on getting FSCTL_OPLOCK_BREAK_NOTIFY won’t always work.
>
>
> 2) Can we get complete filename in FSCTL_OPLOCK_BREAK_NOTIFY as in
>> IRP_MJ_CREATE.
>> 3) If we decide to not allow user to open file then can we fail the
>> request in FSCTL_OPLOCK_BREAK_NOTIFY. In that case, what error we should
>> return.
>>
>
> If I’m understanding the purpose of this behaviour of your filter correctly
> (you decide whether to allow the open based on the results of your
> QueryInformation call, yes?), you have to fail the create.
> STATUS_OPLOCK_BREAK_IN_PROGRESS is a success code; the user already has his
> handle. Trying to do something in a subsequent call would be too late if
> your goal is to prevent certain opens.
>
> See the IRP_MJ_CREATE documentation at
> http://msdn.microsoft.com/en-us/library/ms795806.aspx under
> IrpSp->Parameters.Create.Options. There’s a part about
> FILE_COMPLETE_IF_OPLOCKED. Specifically there’s a bit that says that if
> your filter can’t honour the FILE_COMPLETE_IF_OPLOCKED_FLAG, you should fail
> the create with STATUS_SHARING_VIOLATION.
>
> Please let me know if this helps.
> –
> Christian [MSFT]
>
> This posting is provided “AS IS” with no warranties, and confers no rights.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Christian_Allred · November 19, 2009, 5:05pm

Ashish Goyal wrote:

Thanks Chris…Your comments concreted my understanding on handling OPLOCKS.

As you mentioned that FSCTL_OPLOCK_BREAK_NOTIFY might not be send by all
applications (this was the reason I was looking for sample code), Can I
assume that Network Redirector on windows platform will always send that?

As I’m sure you know, it’s never safe to assume that a particular
behaviour will hold 100% of the time. That said, sending
FSCTL_OPLOCK_BREAK_NOTIFY in response to STATUS_OPLOCK_BREAK_IN_PROGRESS
is what the file server (not the redirector) does in the current
implementation. Also note that this is the recommended behaviour when
getting STATUS_OPLOCK_BREAK_IN_PROGRESS, and is the implemented
behaviour of the file server; any random application can do whatever it
likes.

Again however, remember that if your intent is to fail the user’s create
based on attributes of the file, waiting until FSCTL_OPLOCK_BREAK_NOTIFY
is too late; the user already has his handle.

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

Ashish_Goyal · November 21, 2009, 4:07am

Thanks Chris…So we need to deny the request in Create request
itself…Sounds good.

On Fri, Nov 20, 2009 at 3:34 AM, Christian Allred wrote:

> Ashish Goyal wrote:
>
>> Thanks Chris…Your comments concreted my understanding on handling
>> OPLOCKS.
>> As you mentioned that FSCTL_OPLOCK_BREAK_NOTIFY might not be send by all
>> applications (this was the reason I was looking for sample code), Can I
>> assume that Network Redirector on windows platform will always send that?
>>
>
> As I’m sure you know, it’s never safe to assume that a particular behaviour
> will hold 100% of the time. That said, sending FSCTL_OPLOCK_BREAK_NOTIFY in
> response to STATUS_OPLOCK_BREAK_IN_PROGRESS is what the file server (not the
> redirector) does in the current implementation. Also note that this is the
> recommended behaviour when getting STATUS_OPLOCK_BREAK_IN_PROGRESS, and is
> the implemented behaviour of the file server; any random application can do
> whatever it likes.
>
> Again however, remember that if your intent is to fail the user’s create
> based on attributes of the file, waiting until FSCTL_OPLOCK_BREAK_NOTIFY is
> too late; the user already has his handle.
>
>
> –
> Christian [MSFT]
> This posting is provided “AS IS” with no warranties, and confers no rights.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>