This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/5227] New: opendir and O_CLOEXEC problems with Linux-2.6.9-5.ELsmp kernel


First, I'd like to point out that O_CLOEXEC is not mentioned in the glibc-2.7
manuals.  Nor are the fopen mode flags 'm', 'c' or 'e'.  Should the
manuals be updated to reflect these new features?

I'm experiencing problems with O_CLOEXEC and opendir in glibc-2.7.
There are probably also problems with other glibc functions that use
O_CLOEXEC, but I haven't explored them in detail.

I have two machines with different kernels:
salmonj@drdws032.nyc$ cat /proc/version
Linux version 2.6.18.1-5smp (root@drdwsfe0.nyc.deshaw.com) (gcc version 3.4.4
20050721 (Red Hat 3.4.4-2)) #1 SMP Tue Feb 27 15:02:11 EST 2007

salmonj@drda0047.nyc$ cat /proc/version
Linux version 2.6.9-5.ELsmp (bhcompile@thor.perf.redhat.com) (gcc version 3.4.3
20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005

On the first, open silently ignores the O_CLOEXEC bit.  I.e., it
doesn't "work", but it doesn't cause any problems either.  It looks
like glibc-2.7's use of O_CLOEXEC has been coded with this
possibility in mind.  I configured and built glibc-2.7 on this machine.

On the second, calling open with the O_CLOEXEC bit set causes open to
return -1 with errno=530.  This can cause unexpected failures wherever
glibc uses O_CLOEXEC.  For all I know, this is a kernel bug.  Even so,
the glibc maintainers should make a conscious decision about whether
glibc should cleanly work around it or not.

The one case I looked at in detail is opendir.  I believe it fails
because of this code:

  int flags = O_RDONLY|O_NDELAY|EXTRA_FLAGS|O_LARGEFILE;
#ifdef O_CLOEXEC
  flags |= O_CLOEXEC;
#endif
  int fd = open_not_cancel_2 (name, flags);
  if (__builtin_expect (fd, 0) < 0)
    return NULL;



Here's some code that demonstrates the problem:


salmonj@drda0047.nyc$ cat tstopendir.c
#include <sys/types.h>
#include <dirent.h>
#include <stdio.h>
#include <fcntl.h>

int main(int argc, char **argv){
    DIR *d;
    int fd;
    d = opendir(argv[1]);
    if(d == 0)
        perror("opendir");
    else
        printf("opendir(\"%s\") OK\n", argv[1]);

    return 0;
}
salmonj@drda0047.nyc$ 
salmonj@drda0047.nyc$ xmk tstopendir
cc -std=c99 -I/proj/desres/root/Linux/x86_64/glibc/2.7-01/include
-Wl,-dynamic-linker=/proj/desres/root/Linux/x86_64/glibc/2.7-01/lib/ld-2.7.so 
tstopendir.c   -o tstopendir
salmonj@drda0047.nyc$ ls -ld junk
drwxrwsr-x  2 salmonj salmonj 4096 Oct 27 20:46 junk/
salmonj@drda0047.nyc$ ./tstopendir junk
opendir: Unknown error 530
### This is very strange.  "." and ".." don't have the same problem:
salmonj@drda0047.nyc$ ./tstopendir .
opendir(".") OK
salmonj@drda0047.nyc$ 

# And here's evidence that O_CLOEXEC is the underlying problem.
salmonj@drda0047.nyc$ cat tstcloexec.c
#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv){
    int fd = open(argv[0], O_RDONLY|O_CLOEXEC);
    if(fd<0)
        perror("open");
    else
        printf("open(%s, O_RDONLY|O_CLOEXEC) OK\n");
    return 0;
}
salmonj@drda0047.nyc$ salmonj@drda0047.nyc$ xmk tstcloexec
cc -std=c99 -I/proj/desres/root/Linux/x86_64/glibc/2.7-01/include
-Wl,-dynamic-linker=/proj/desres/root/Linux/x86_64/glibc/2.7-01/lib/ld-2.7.so 
tstcloexec.c   -o tstcloexec
salmonj@drda0047.nyc$ tstcloexec
open: Unknown error 530

John Salmon

-- 
           Summary: opendir and O_CLOEXEC problems with Linux-2.6.9-5.ELsmp
                    kernel
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: john at thesalmons dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=5227

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]