Samba 3.0.32 - oplock code

[Itay Dar]

Hi, 

We are working on a cluster, so if the process will die in the middle of
the change phase you are proposing, a state corruption will occur.
So this makes life hard on us, as we need to start working with
transactions (I think the ctdb project will have the same issues, but I
am not sure, I plan to look on it also)

I was thinking on just marking the breaker entry as downgrade one and
than sending a notify to all.  
And checking In open code path if this is a downgraded one, I am testing
this change and it seems to work (but I had to touch lot of files)
I am giving it a bit more qa time before posting.

An alternative was to break to the client (or just remove the fake
oplock ) under the lock and than send notify to everyone else, this will
do the same trick.

Many thanks for the patch lookup.
itay

-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Thursday, December 11, 2008 7:10 PM
To: Itay Dar
Cc: jra at samba.org; samba-technical at lists.samba.org
Subject: Re: Samba 3.0.32 - oplock code

On Thu, Dec 11, 2008 at 11:22:02AM +0200, Itay Dar wrote:
> Hi,
> Yes, it solves my original posting, but the following case Is missing.

> If someone is asking for an oplock level two and at least one share 
> lock entry doesn't have a level two oplock or a fake one, than this 
> request should be also denied.
> Also  an exclusive oplock cant be granted  if no one has an oplock 
> level two, but that seems as a code glitch.
> 
> I am attaching my patch suggestion below.
> 
> I have also notice there is a potential  race between the 
> release_level_2_oplocks_on_change and the open_file_ntcreate
functions.
> Lets say someone just issued a release_level_2_oplocks_on_change call,

> he will take the tdb lock, send the oplock break request to everyone 
> else (including himself) and than unlock the share entry, lets say 
> someone is waiting on the tdb lock coming from the open_file_ntcreate 
> , he will view the share entries notice they are all having an level 
> two oplock or a fake one, and will get himself a level two oplock, but

> all other owners are going to be downgrade to a non oplock so future 
> changes coming from them wont reach him.
> I will try to think on a possible remedy, and send a suggestion.

An alternative is to send out the messages to all
level2 holders and then have the lock holding process do the downgrades
on the share mode data itself whilst holding the lock rather than have
the receiving processes do it after they got the message.

I think that will remove the race and won't introduce any possible
errors - after all, sending the messages out to the clients are
asynchronous anyway.

I'll take a look at your patch, but won't be able to commit anything
until Tues of next week.

Cheers,

Jeremy.