SMBtrans2 oplock safety
jra at samba.org
Fri Jul 19 09:22:02 GMT 2002
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.
More information about the samba-technical