This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/5227] New: opendir and O_CLOEXEC problems with Linux-2.6.9-5.ELsmp kernel
- From: "john at thesalmons dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 28 Oct 2007 01:21:38 -0000
- Subject: [Bug libc/5227] New: opendir and O_CLOEXEC problems with Linux-2.6.9-5.ELsmp kernel
- Reply-to: sourceware-bugzilla at sourceware dot org
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.