Oplock timing issue.

[Jeremy Allison]

On Thu, Jun 07, 2001 at 12:02:40PM -0500, Scott Prather wrote:
> Yes it is, 2.4.2 from SuSe.  We also have problems on AIX (no kernel oplocks), but it takes longer for this to show up.  I think the problem is the smbd trying to open the file is not waiting long enough for the oplock to break before calling fd_open, as it seems from the timestamps that the oplock break is still processing during the actual open of the file.   This is Samba 2.2.0, we have not had any problems with 2.0.7.

2.0.7 doesn't use kernel oplocks - which is probably why
you're not seeing the problem. I doubt this is the same issue
on AIX.

> A network trace shows that the response to the close of the file is sent at almost the same time as the response to the open from the second file.  In previous files that are opened with oplock (for examlpe cpuid32.dll), the client that is requested to break the oplock sends a LockAndX response.  In the case of client.cfg, the client returs a close in response to the oplock break request.

The close should get passed down to the kernel and
then that should free up the smbd blocked on the kernel
lease. The difference in the Samba code between the
lockingandX return and the close return is that Samba
explicitly removes the kernel lease on the lockingandX
return, but expects the kernel to do it on the close()
call.

It wouldn't be too hard to hack the close() path to
explicitly remove the kernel oplock, and see if this
fixes the problem. If it does, it points to a bug 
in the kernel code.

Jeremy.