Bug 1923 - File record locks cannot be unlocked (fcntl F_UNLCK fails)
File record locks cannot be unlocked (fcntl F_UNLCK fails)
Status: RESOLVED WORKSFORME
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 major
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-12 22:16 UTC by Rob Swindell
Modified: 2004-11-17 16:42 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Swindell 2004-10-12 22:16:09 UTC
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;
}
Comment 1 Rob Swindell 2004-10-12 23:05:55 UTC
I failed to mention the obvious: this same test runs file on a local file 
system, or even an smbfs-mounted file system.

-Rob
Comment 2 Steve French 2004-10-13 08:37:10 UTC
yes - this seems to have regressed with Trond's changes to Linux vfs (posix 
locking fixes).
Comment 3 Steve French 2004-10-13 18:26:32 UTC
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
Comment 4 Rob Swindell 2004-10-15 15:08:21 UTC
(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
Comment 5 Rob Swindell 2004-10-20 15:54:21 UTC
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
Comment 6 Rob Swindell 2004-11-02 20:32:34 UTC
Still waiting on a fix for this one. Any status update would be appreciated. 
Thanks,

-Rob
Comment 7 Rob Swindell 2004-11-15 21:40:42 UTC
Testing, 1, 2, 3. Is this thing on?

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

Please, anything. Hello?
Comment 8 Steve French 2004-11-16 10:26:49 UTC
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 
Comment 9 Rob Swindell 2004-11-17 13:15:08 UTC
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
Comment 10 Steve French 2004-11-17 16:42:20 UTC
No longer appears to fail. Please reopen if you see it again on current code.