Samba oplock level II problem

[Pavel Shilovsky]

2011/2/5 Jeremy Allison <jra at samba.org>:
> On Fri, Feb 04, 2011 at 02:37:06PM -0800, Jeremy Allison wrote:
>> On Fri, Feb 04, 2011 at 11:11:54PM +0300, Pavel Shilovsky wrote:
>>
>> > I think you missed new byte-range locking part.
>>
>> Yes you are correct.
>>
>> > Now we may have the
>> > following situation:
>> > 1) f1 = open(file) # exclusive oplock is granted to f1
>> > 2) lock(f1) # set byte-range lock via f1
>> > 3) f2 = open(file) # f1 gets oplock break with level2 but no oplock is
>> > granted to f2 (because lock count more 0) - we have 'no oplock' for f2
>> > and 'level2' oplock for f1 in share mode entries
>>
>> Ah, that's a bug in your original patch then - it's
>> refusing the oplock in the wrong place (or at least
>> not forcing an overall downgrade). We need to
>> make sure we can't have that situation where the no_oplock
>> and level2 oplock co-exist in the share mode entries without
>> it being in a transitional stage to "no oplock" over all
>> entries.
>>
>> I'll take a closer look at the underlying issue.
>
> Ok, the following patch (to 3.6 and master) fixes
> the problem. It moves your original patch into smbd/open.c
> from smbd/oplock.c as we need to decide before we set
> share mode entries.
>
> I'll need to work on the 3.5.x patch you posted, that
> will have to be moved also but that's a harder change
> as I already refactored the 3.6.x code to make this
> clearer.
>
> Jeremy.
>

If I understand you right and we should set FAKE_LEVEL_II_OPLOCK to f2
on the line 3 of my example, I agree with your changes. So, as the
result for my example, we have two entries:
1) f1 - level2 oplock;
2) f2 - fake leve2 oplock.

So, in this case the check for level2_oplock_type in
contend_level2_oplocks_begin_default is correct.

I can respin my patch (move brlocks check into delay_for_oploks in
open.c) to make it according to the note above.

-- 
Best regards,
Pavel Shilovsky.