Bug 5980 - Race condition when granting level2 oplocks can cause break notify to be missed.
Race condition when granting level2 oplocks can cause break notify to be missed.
Status: RESOLVED FIXED
Product: Samba 3.2
Classification: Unclassified
Component: File services
unspecified
Other All
: P3 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-17 19:35 UTC by Jeremy Allison
Modified: 2013-08-16 10:51 UTC (History)
0 users

See Also:


Attachments
Patch (1.44 KB, patch)
2008-12-18 15:31 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2008-12-17 19:35:55 UTC
A client that views a file and sees all entries having a level two oplock
(fake or not) should get a level two oplock fake or real depending on his
request.

now when a client decides to break all level2 oplocks he send everyone an aync
oplock break under the tdb lock (including to himself) then he frees the tdb
lock.
lets say some open request waited on that tdb lock, the request cant know a
downgrade had happend so it will get a level two oplock, but no other owner
will notify it on changes.

This is solved basicly by changing the share entry data under the tdb lock,
before or after sending the oplock break requests. (the tdb lock is what
counts)

here there are 3 options :
1. have a new state and keep the reguler flow the same (sending the async
oplock to breaker client as an async event)

2. send the client the oplock break request from the release function and
update the share entry database.

3. send the client a break and update all other share entries also.

Number one is my orignal suggestion, but number two seems as the best solution
possible.

i will try to look into the code of the samba tourte suit and see if i can
ehance it.

many thanks,

itay dar
Itay Dar <Itay.Dar@exanet.com>
Comment 1 Jeremy Allison 2008-12-18 15:31:01 UTC
Created attachment 3817 [details]
Patch

Patch for 3.2.x and above.
Jeremy.
Comment 2 Björn Jacke 2009-02-11 04:23:51 UTC
this one seems to be pushed to 3.2 (3a8ca840) and above. Can we be sure the problem is fixed and the bug can be closed?