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

["john at thesalmons dot org" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From john at thesalmons dot org  2007-10-29 03:28 -------
Fair enough - glibc doesn't work around kernel bugs.

How about widely deployed kernel "enhancements"?  It turns out that the problem
is that the machine on which opendir fails has a RedHat EL kernel with TUX
enhancements, and that kernel (and presumably thousands like it) was compiled
with the following in fcntl.h:

#define O_NOATIME	01000000
#define O_ATOMICLOOKUP	02000000 /* TUX */

So my kernel thinks that the 02000000 bit of OFLAGS is a request for an
ATOMICLOOKUP, but glibc (and the linux main line kernels since 2.6.something)
thinks that it's a request to set the close-on-exec bit.  Wonderful.

I can understand if glibc mainenance team simply refuses to deal with
non-standard kernels.  You have to draw the line somewhere.  

But at least let's have a test so people who run 'make check' won't think
they've got a working library when they don't.  I've attached 'opendir-tst2.c'
that fails on my RHEL system but that works fine on my 2.6.18 system.  Note that
the first opendir succeeds - we just created tmpXXXX, so it's very likely in the
dentry_cache, and hence O_ATOMICLOOKUP has no problem.  Trying to
opendir("tmpXXX/doesnotexist") on the other hand is a miss in the dentry cache
and fails the ATOMICLOOKUP test, leading to a non-standard errno which we can
test for. Lucky for us that the TUX patches set errno to the crazy value of 530
when the dentry cache lookup fails.  If not for that, I wouldn't know how to
reliably reproduce the problem.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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.