Bug in implementation of fcntl64 syscall?

Hi,
I'm trying to investigate why my apache compiled with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (and glibc 2.2 build against 2.4.0-test10 headers) immediately dies with

[emerg] (11)Resource temporarily unavailable: fcntl:
F_SETLKW: Error getting accept lock, exiting!

This happens while trying to get the file lock to serialize accept. The first child gets the lock, the other should block. However, fnctl(fd, F_SETLKW, ...) returns with EAGAIN (which shouldn't be possible, it would be correct for F_SETLK). Note that for the above compile flags, libc's F_SETLKW is 14 (on i386) which in the kernel is F_SETLKW64 (kernel's F_SETLKW is 7). strace shows that the actual system call used by libc is fcntl64. For 2.4.0-test11, fs/fcntl.c has the following code:

asmlinkage long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg )

{       
	...
        switch (cmd) {
                case F_GETLK64:
                        err = fcntl_getlk64(fd, (struct flock64 *) arg);
                        break;
                case F_SETLK64:
                        err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
                        break;
                case F_SETLKW64:
                        err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
                        break
	...

i.e. fcntl_setlk64() is called with cmd==F_SETLKW64, but in fs/locks.c:

int fcntl_setlk64(unsigned int fd, unsigned int cmd, struct flock64 *l)

{
	...
        error = posix_lock_file(filp, file_lock, cmd == F_SETLKW);
                                                        ^^^^^^^^

where the last argumet to posix_lock_file governs
wait vs. immediate return.

Cheers, Roderich

      "Thou shalt not follow the NULL pointer 
       for chaos and madness await thee at its end."

Roderich Schupp 		mailto:[email protected]
ExperTeam GmbH			http://www.experteam.de/
Munich, Germany

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/