Bug in implementation of fcntl64 syscall?

Bug in implementation of fcntl64 syscall?

[Roderich Schupp]

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:rsch@ExperTeam.de
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/