SMBtrans2 oplock safety

[Jeremy Allison]

On Fri, Jul 19, 2002 at 11:16:19AM -0400, Lev Iserovich wrote:
> Hi all,
> 
> I've encountered a problem in a win2k machine communicating with a samba 
> 2.2.5 server.
> Sometimes a file open on the win2k machine hangs for 30 seconds, and 
> then after a message to the samba event log like :
> 
>   oplock_break: *receive_smb* timed out after 30 seconds.
> 
> 
> the open finally goes through.
> Doing a lot of network traces revelead the following :
> The client requests a file open, while already having the file open, and 
> holding a batch oplock on the file.
> The server sends an oplock_break request to the client. This requests 
> crosses with a SMBtrans2 QUERY_PATH_INFO request on the same filename on 
> the wire. The smb server, I believe due to SMBtrans2 being marked as 
> QUEUE_IN_OPLOCK in smbd/process.c, it is queued until the oplock_break 
> reply is recieved.
> The problem is that for some weird reason, win2k does not seem to want 
> to acknowledge the oplock_break until it receives the reply to the 
> path_info query.
> I found this because after 30 seconds, samba gives up, breaks the 
> oplock, and grants the open request. It also replies to the queued 
> path_info query, right after which the client returns the oplock_break 
> response (which is too late obviously, and is reported as "oplock_break 
> reply recieved, but no oplocks granted on this file" in the log.)
> 
> I think the only subfunction in SMBtrans2 which depends on not being 
> called with outstanding oplock breaks is the trans2open function, which 
> internally already has protection against this situation. Therefore I 
> think the QUEUE_IN_OPLOCK flag for SMBtrans2 should be removed.
> 
> Is this safe to do?
> If so, this should be cheked in as it would solve this issue.

*Great* detective work - can you give me a test case to reproduce
this ? I would love to know exactly how to test this.

Could you try removing the QUEUE_IN_OPLOCK flag for both
reply_trans2 and reply_nttrans as they are both internally
protected against this problem and test again for me.

I would like to know about this problem asap so I can get it
checked in and tested for 2.2.6.

Thanks,

	Jeremy.