I failed to mention the obvious: this same test runs file on a local file 
system, or even an smbfs-mounted file system.

-Rob

yes - this seems to have regressed with Trond's changes to Linux vfs (posix 
locking fixes).

I had been able to reproduce an unlock error over cifs using connectathon 
test7, but when I try your lock test case (adding in the missing line of code 
to initialize the alock.l_type field to a RDLOCK) I don't get an error on 2.6.9-
rc4 to either Samba 3.0.7 or Windows XP as server.  

Thought it was the same problem - perhaps not.  There was a bug in cifs locking 
code on bigendian not sure whether that is it because it has been fixed - 
perhaps earlier than 2.6.8 code.

I will try with fc2 later tonight

(In reply to comment #3)

Here's an updated version of the test case code:

/* locktest.c */

#include <fcntl.h>      /* O_RDONLY */
#include <unistd.h>     /* L_SET */
#include <errno.h>      /* errno, EINVAL */

#define OFFSET          0
#define LENGTH          1

int main(int argc, char** argv)
{
        int fd;
        struct flock alock;

        if(argc<2) {
                printf("usage: %s <filename>\n", argv[0]);
                return -1;
        }
        if((fd = open(argv[1], O_RDONLY))==-1) {
                perror("!error opening file");
                return errno;
        }

        alock.l_whence = L_SET;
        alock.l_start = OFFSET;
        alock.l_len = LENGTH;
        alock.l_type = F_RDLCK;

        if(fcntl(fd, F_SETLK, &alock)!=0)
                perror("!ERROR locking file");
        else
                printf("%s locked\n", argv[1]);

        alock.l_type = F_UNLCK;   /* remove the lock */
        if(fcntl(fd, F_SETLK, &alock)!=0)
                perror("!ERROR unlocking file");
        else
                printf("%s unlocked\n", argv[1]);

        close(fd);

        return 0;
}

/* end */

Again, this code runs fine on files in local or smbfs-mounted directories, but 
produces the following error on an cifs-mounted directories:

!ERROR unlocking file: Input/output error

Any progress on this bug? :-)

Should I be looking to run a differnet kernel version (2.6.9?) or reverting to 
smbfs or what?

Thanks,

-Rob

Still waiting on a fix for this one. Any status update would be appreciated. 
Thanks,

-Rob

Testing, 1, 2, 3. Is this thing on?

I'm sorry, did I forget the "secret handshake" or something?

Please, anything. Hello?

I would like to fix it if I could reproduce the bug.  I tried it against Samba 
3.0.8 a few minutes ago on FC2 running current code (2.6.10-mm tree) and it did 
not fail.  I am not aware of anything in particular that would have fixed this.

I also tested it to WindowsXP server and the test worked fine.  No dmesg 
output, no error in testcase, no error on the wire.

I used to see a dmesg error when running connectathon lock test (number 7 I 
think) but when inserting any print statements the timing changed enough to 
remove the error and this is somewhat lower on the priority list to investigate 
than the finish off the more complicated cifs_readdir rewrite.

There are a couple of options next - with a network trace of the failure and 
corresponding dmesg info (with /proc/fs/cifs/cifsFYI) enabled we might be able 
to narrow it down.  There 

After upgrading to FC3, the locktest now passes.

version:        1.20 BD05AA287A833DA8A57BDC6
vermagic:       2.6.9-1.667 686 REGPARM 4KSTACKS gcc-3.4

-Rob

No longer appears to fail. Please reopen if you see it again on current code.