Bug 7923 - Oplock level II problem with byte-range locks
Oplock level II problem with byte-range locks
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: File services
unspecified
All Linux
: P3 major
: ---
Assigned To: Andrew Bartlett
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-17 09:55 UTC by Pavel Shilovsky
Modified: 2011-02-15 04:05 UTC (History)
2 users (show)

See Also:


Attachments
Capture from the description (7.45 KB, application/octet-stream)
2011-01-17 09:58 UTC, Pavel Shilovsky
no flags Details
Script that reproduces the problem (604 bytes, text/plain)
2011-01-21 06:17 UTC, Pavel Shilovsky
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Shilovsky 2011-01-17 09:55:03 UTC
Samba-4.0.0-alpha14 grants oplock level II to the first client while the second keeps byte-range lock on this file. So, this causes the error with page reading in cifs kernel client (with newly introduced strict cache mode that haven't merged yet).

A attached the capture, it's main points are following:
1) client_1 opens file - gets exclusive oplock on 0x0001 fid (#15)
2) client_2 opens file - gets oplock level II on 0x0002 fid (#22)
3) client_1 gets oplock break on 0x0001 - gets oplock level II (#19)
4) client_2 locks file from 1 to 2 on 0x0002 fid (#24)
5) client_1 and client_2 get oplock breaks - no oplock (#26-30)
6) client_1 opens file - gets oplock level II on 0x0003 fid (#36) - ERROR!!!
7) client_1 fails on pagereading - according to oplock level II - pagereading is ok

I looked through Samba sources and didn't find any lock-specific checks while granting oplocks (for Samba-3.6 and for Samba-4.0.0 stable branches code). So, I can't reproduced it with Samba-3.6 but it may depend on a situation.
Comment 1 Pavel Shilovsky 2011-01-17 09:58:43 UTC
Created attachment 6207 [details]
Capture from the description
Comment 2 Pavel Shilovsky 2011-01-21 06:17:42 UTC
Created attachment 6219 [details]
Script that reproduces the problem
Comment 3 Pavel Shilovsky 2011-01-21 06:42:21 UTC
smb.conf:

# Global parameters
[global]
	server role = domain controller
	workgroup = TESTGROUP
	realm = test-name
	netbios name = TEST
	setup directory = setup/

[netlogon]
	path = /usr/local/samba4/var/locks/sysvol/localhost/scripts
	read only = No

[sysvol]
	path = /usr/local/samba4/var/locks/sysvol
	read only = No

[test]
	path = /mnt/samba_share
	read only = No
Comment 4 Volker Lendecke 2011-01-21 06:50:26 UTC
Quick question: Does this also happen with 3.5.6 on the server side?

Thanks,

Volker
Comment 5 Matthias Dieter Wallnöfer 2011-01-21 07:00:15 UTC
Is the problem more client or server related?

If server related then a problem is the fact, that s4's file server at the moment is unmaintained. That means, each time if possible, please try using s3 or somewhat else (on another server) for this purpose. Newer s3 winbind daemons should be working against s4 therefore there shouldn't be integration problems.
But if you are keen to write a patch then we will happy to apply it.

We are working to allow s3's file server to be run on top of s4 (or vice versa) but till now no adaption/approach has made it to an end yet.
Comment 6 Pavel Shilovsky 2011-01-21 10:42:14 UTC
(In reply to comment #4)
> Quick question: Does this also happen with 3.5.6 on the server side?
> 
> Thanks,
> 
> Volker
> 

I can't caught it with Samba-3.5.6 in both cases: with 'kernel oplocks = no' (to enable level2 oplocks) and without it (level2 oplocks are disabled); and it's behaviour was ok.

Comment 7 Pavel Shilovsky 2011-01-21 10:43:10 UTC
(In reply to comment #5)
> Is the problem more client or server related?

it's server related.
Comment 8 Pavel Shilovsky 2011-01-21 12:21:01 UTC
I caught this bug with Samba-3.6 - so, it's not a Samba-4.0.0 specific bug. I suggest to move the discussion to https://bugzilla.samba.org/show_bug.cgi?id=7928.

*** This bug has been marked as a duplicate of bug 7928 ***
Comment 9 Pavel Shilovsky 2011-02-01 06:25:15 UTC
(In reply to comment #5)
> But if you are keen to write a patch then we will happy to apply it.
> 

I wrote the patch that fixes the problem for Samba-4.0.0-alpha14:

http://git.etersoft.ru/people/piastry/packages/?p=samba4.git;a=commitdiff;h=f5e27f15c653071b257b22dc1dca9f46491cd6dd
Comment 10 Matthias Dieter Wallnöfer 2011-02-01 10:10:07 UTC
Okay, then let us reopen this.

I'm adding metze for a patch review. Metze, could you do the review and merge this if it's fine?
Comment 11 Stefan Metzmacher 2011-02-01 10:14:28 UTC
If this gets braces:

+       if (count != 0)
+               oplock_level = OPLOCK_NONE;

I think the patch is fine as long as it passes make test.
Comment 12 Pavel Shilovsky 2011-02-01 13:44:58 UTC
(In reply to comment #11)
> If this gets braces:
> 
> +       if (count != 0)
> +               oplock_level = OPLOCK_NONE;
> 
> I think the patch is fine as long as it passes make test.
> 

It passes samba4.raw.oplock test with new test that shows this bug http://git.samba.org/?p=samba.git;a=commitdiff;h=f453235ce057339a69398f5c862fdd3e46bd31c4

As for braces - should I respin the patch with new version?
Comment 13 Matthias Dieter Wallnöfer 2011-02-01 13:47:08 UTC
Yeah, please do!

(In reply to comment #12)
> 
> As for braces - should I respin the patch with new version?
> 

Comment 14 Pavel Shilovsky 2011-02-01 13:58:17 UTC
Respin the patch with braces around count variable check:
http://git.etersoft.ru/people/piastry/packages/?p=samba4.git;a=commitdiff;h=d02f3542a8ffc49c1250c15c2ef21748d2abea8b
Comment 15 Matthias Dieter Wallnöfer 2011-02-04 01:53:57 UTC
Metze would you or should I push the fix?
Comment 16 Matthias Dieter Wallnöfer 2011-02-15 04:05:36 UTC
Patch should soon land in "master".