Samba oplock level II problem
Pavel Shilovsky
piastryyy at gmail.com
Wed Feb 9 01:35:47 MST 2011
2011/2/6 Pavel Shilovsky <piastryyy at gmail.com>:
> 2011/2/5 Pavel Shilovsky <piastryyy at gmail.com>:
>> 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.
>>
>
> I recreated the patch for 3.5.x:
> http://git.etersoft.ru/people/piastry/packages/?p=samba4.git;a=commitdiff;h=0ce27557e831490fe31493c339e546078f504c51
>
> --
> Best regards,
> Pavel Shilovsky.
>
What's about this? When is the next Samba-3.5.x expected to release?
--
Best regards,
Pavel Shilovsky.
More information about the samba-technical
mailing list