[linux-cifs-client] Re: Bug in cifsfs POSIX locking client code.

[Jeremy Allison]

On Tue, Jul 11, 2006 at 10:18:20PM -0700, Jeremy Allison wrote:
> Steve,
> 
> 	I'm testing cifsfs using tdbtorture on a 
> current SAMBA_3_0 tree smbd mounted drive and it's
> failing. It seems that you're not waiting long
> enough for a blocking POSIX lock. I see in the
> /var/log/messages things like :
> 
> Jul 11 21:56:44 linux kernel:  CIFS VFS: No response for cmd 50 mid 40847
> 
> When I trace that mid in the server, I find it's a
> request for a lock that hasn't been freed yet - ie.
> it *should* still be blocking.
> 
> When you issue a blocking POSIX fcntl lock it should
> wait *forever* until the server responds to it. There
> shouldn't be a timeout on this other than the connection
> going down.
> 
> I'm looking in the current code but don't see where
> you set timeouts for blocking locks yet....

Ok, here are a couple of patches for cifsfs.

The first one ensures you don't select POSIX FCNTL locks
unless experimental is on - otherwise you select them (and
the smbd server is in a state where it expects them) and
then you don't send them if "experimental" isn't turned on.

The second patch is to add timeout values to the set
posix fcntl lock call. It sets this in the same way as
you do for the Windows lockingX call. Unfortunately it
doesn't seem to make a difference. The client still seems
to be arbitrarily disconnecting from the server (I'm getting

read_data: read of 4 returned 0. Error = Success
receive_smb_raw: length < 0!
timeout_processing: End of file from client (client has disconnected).

messages in my logs over loopback which means the client
is disconnecting and I don't know why).

I'm guessing the waiting for blocking calls still isn't
working correctly....

I'm quite confident of the posix locking code in the server -
it's passing all of the userspace tests I can throw at it,
and I think it's quite robust. We need to get cifsfs the
same for blocking calls I think.

Jeremy.