version: 1.20 23F52D34CA51E6EDFF8D55A vermagic: 2.6.8-1.521 686 REGPARM 4KSTACKS gcc-3.3 Using Windows 2000 for file server, the following test code running on FC2 w/2.6.8 kernel fails with the following message: !ERROR unlocking locktest.c: Input/output error /* locktest.c */ #include <fcntl.h> /* O_RDONLY */ #include <unistd.h> /* L_SET */ #include <errno.h> /* errno, EINVAL */ #define FILENAME "locktest.c" #define OFFSET 0 #define LENGTH 1 int main(void) { int fd; struct flock alock; if((fd = open(FILENAME, O_RDONLY))==-1) { perror("!ERROR opening " FILENAME); return errno; } alock.l_whence = L_SET; alock.l_start = OFFSET; alock.l_len = LENGTH; if(fcntl(fd, F_SETLK, &alock)!=0) perror("!ERROR locking " FILENAME); else printf("%s locked\n", FILENAME); printf("Hit any key..."); getchar(); alock.l_type = F_UNLCK; /* remove the lock */ if(fcntl(fd, F_SETLK, &alock)!=0) perror("!ERROR unlocking " FILENAME); else printf("%s unlocked\n", FILENAME); printf("Hit any key..."); getchar(); close(fd); return 0; }
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.