oplocks and queued messages

[Jeremy Allison]

John Gregson wrote:
> 
> Hi,
> 
> This is not really a bug-report but I thought you may be interested in a
> problem that hit us when using oplocks. We have solved it by changing
> Samba slightly and have subsequently discovered that NT 4 acts in the
> same respect as our change (superficially at least).
> 
> We have a share (say data) and applications access this share at user
> login. We see that the following occurs when there are two opens on the
> file software.ini on the share data.
> 
> The first open asks for and gets an oplock on software.ini.
> 
> The second open asks for an oplock.
> 
> The server then sends a Locking_andX message to break the oplock for the
> first open.
> 
> The client then sends a Trans2 message to get file system information.
> 
> Now at this stage a deadlock occurs as Samba now queues this message as
> it is in an oplock break state; however it never gets the oplock break
> reply from the client as it (the client) seems to be waiting for the
> reply to the Trans2.
> 
> If we change the flags for the Trans2 message to exclude the
> QUEUE_IN_OPLOCK flag the the problem goes away. The server sends the
> Trans2 reply and then receives the oplock break reply from the client.
> 
> I can guess the reasoning behind the QUEUE_IN_OPLOCK flag for the Trans2
> message but interestingly we ran the same test with NT serving the share
> and saw that it also sent the Trans2 reply before receiving the oplock
> break reply.
> 
> I must admit that we haven't tested our change extensively but it's not
> caused us any problems so far.
> 
> Any comments/warnings?

John,

	Thanks for that bug report. I'm CC:ing the samba-technical
list on the reply as I think people on it will be interested in
the gory details :-).

It *is* a Samba bug - the QUEUE_IN_OPLOCK was added to
all trans2 calls as one of the trans2 calls allows a
file open (which would cause the deadlock that the
QUEUE_IN_OPLOCK code was added to prevent). As NT
never seems to issue the trans2 open calls your fix
will probably work correctly, but not with an
oplock-aware client that uses the trans2 open
call (not that I'm aware of any such client :-).

The correct fix is to remove the QUEUE_IN_OPLOCK
flag from the trans2 call (as you have done) but
also add code to ensure that a trans2 open call
is queued when smbd is in the oplock break state
- I'll add this to the main branch (and probably
the 1.9.18 branch code also).

Thanks a lot for the bug report,

Cheers,

	Jeremy Allison,
	Samba Team.


-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------