Am 18.11.2014 um 02:09 schrieb Jeremy Allison:
> On Mon, Nov 17, 2014 at 08:02:38PM +0100, Stefan (metze) Metzmacher wrote:
>>>> It would also be good to verify this section with a test:
>>>> if (lp_locking(fsp->conn->params) && file_has_brlocks(fsp)) {
>> DEBUG(10,("grant_fsp_oplock_type: file %s has byte range
>> locks\n",
>> fsp_str_dbg(fsp)));
>> granted &= ~SMB2_LEASE_READ;
>> }
>>>> We need to make sure we never grant "W" or WH" leases.
>> Yes, looking at this right now it would seem
> that if we did:
>> open RWH LEASE1 ->
> <- reply RWH, H1
> locking H1 ->
> <- OK
> open RWH LEASE1 ->
>> we would reply with (WH, H2) - which should
> not be allowed. Windows clients don't do this,
> which is why we wouldn't have caught this before.
>> I'll check with a test.
>>> It's also unclear to me why a client shouldn't be able to get a read lease,
>> when it already has brlocks (and a possible write lease).
>>>> Do we have an oplock related test for this already?
>> Yeah, we do have some SMB2 oplock + byte range
> lock tests, but I don't think it checks this
> specific case.
We also need tests for the
contend_level2_oplocks_begin(fsp, LEVEL2_CONTEND_WINDOWS_BRL)
case.
Should this break also a "RW" or "RWH leases?
What happens for "R" and "RH" leases?
Does it break its own lease?
metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141118/5e4d3867/attachment.pgp>