Bug 426890 - ABI incompatibility between glibc 2.7 and RHEL5/RHEL4 (aka O_CLOEXEC vs O_ATOMICLOOKUP aka Unknown error 530)
ABI incompatibility between glibc 2.7 and RHEL5/RHEL4 (aka O_CLOEXEC vs O_ATO...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity high
: rc
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-27 20:48 EST by Axel Thimm
Modified: 2008-07-18 00:42 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHEL5.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-18 00:42:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Axel Thimm 2007-12-27 20:48:59 EST
Description of problem:
RHEL4/5 has the following flag definition
#define O_ATOMICLOOKUP  02000000        /* do atomic file lookup */
while glibc 2.7 requires
#define O_CLOEXEC       02000000        /* set close_on_exec */

This means that a glibc 2.7 open call may (very often) fail on RHEL5 or RHEL4.
This holds for chrooted Fedora 8 systems for example as well as future RHEL6
builds on a RHEL5 machine. Statically built binaries from F8 will fail as well.

Version-Release number of selected component (if applicable):
any

How reproducible:
very often

Steps to Reproduce:
1.setup an F8 chroot on RHEL5
2.Do something in the F8 chroot until you hit unknown error 530 or just some
  strange failure (like su not working due to /etc/passwd not opening due to
  error 530.
3.
  
Actual results:
Unknown error 530 or even more obfuscated open failures

Expected results:
Forward ABI compatibility with glibc

Additional info:
Bugzilla at glibc where this is being discussed:
http://sourceware.org/bugzilla/show_bug.cgi?id=5227
Various random "unknown error 530" encounters where users have no idea what this
error means and that it is a kernel/glibc ABI incompatibility
http://www.google.com/search?q=%22Unknown+error+530%22

This bug is quite hard to track down, as
o it is non-deterministic
o the error message is not helpful at all ("Unknown error 530")
o Quite often there is no errno returned at all (like when pam or nss try to
  access files and fail)
Comment 1 Axel Thimm 2007-12-28 04:56:31 EST
(In reply to comment #0)
> RHEL4/5 has the following flag definition
> #define O_ATOMICLOOKUP  02000000        /* do atomic file lookup */

That was only half true (e.g. only for RHEL5) - in order to not confuse people
reading this here is the full story: RHEL3/RHEL4 had O_ATOMICLOOKUP defined as
01000000 and RHEL5 shifted it a bit higher to make space for O_NOATIME:

el3-i386: /usr/include/asm/fcntl.h:#define O_ATOMICLOOKUP       01000000 /* do
atomic file lookup */
el3-x86_64: /usr/include/asm-i386/fcntl.h:#define O_ATOMICLOOKUP        01000000
/* do atomic file lookup */
el3-x86_64: /usr/include/asm-x86_64/fcntl.h:#define O_ATOMICLOOKUP      1000000 
el4-i386: /usr/include/asm/fcntl.h:#define O_ATOMICLOOKUP       01000000 /* do
atomic file lookup */
el4-x86_64: /usr/include/asm-i386/fcntl.h:#define O_ATOMICLOOKUP        01000000
/* do atomic file lookup */
el4-x86_64: /usr/include/asm-x86_64/fcntl.h:#define O_ATOMICLOOKUP      1000000 
el5-i386: /usr/include/asm-generic/fcntl.h:#define O_NOATIME    01000000
el5-i386: /usr/include/asm-generic/fcntl.h:#define O_ATOMICLOOKUP       02000000
       /* do atomic file lookup */
el5-x86_64: /usr/include/asm-generic/fcntl.h:#define O_NOATIME  01000000
el5-x86_64: /usr/include/asm-generic/fcntl.h:#define O_ATOMICLOOKUP     02000000
       /* do atomic file lookup */

Still this shift was not enough as glibc 2.7 now claims this bit for close on exit.

How about moving all non-standard open flags to the highest possible location,
for example
#define O_ATOMICLOOKUP     40000000

That way any future official flag extension will not collide with any RHEL
specific patches (unless the bits run out).
Comment 2 Axel Thimm 2007-12-28 14:51:34 EST
This is probably a duplicate of bug #358661, but the latter is protected and I
can't read it. Jakub Jelinek pointed me to
http://people.redhat.com/dzickus/el5/62.el5, and according to the changelog this
is fixed since

* Thu Dec 20 2007 Don Zickus <dzickus@redhat.com> [2.6.18-62.el5]
[...]
- [misc] tux: get rid of O_ATOMICLOOKUP (Michal Schmidt ) [358661]
[...]

So RHEL5.2 seems to have this already fixed, thanks a lot!

I'll use the 62 from now on and report back.
Comment 3 Linda Wang 2008-06-06 06:22:20 EDT

*** This bug has been marked as a duplicate of 358661 ***
Comment 4 Axel Thimm 2008-06-07 05:26:24 EDT
Please don't close public bugs as duplicate of private ones:

> You are not authorized to access bug #358661. To see this bug,
> you must first log in to an account with the appropriate permissions.
> 
> Access to some bugs is restricted due to embargoed security issues or respect
> for customer and partner information which must remain confidential. 
Comment 5 Linda Wang 2008-06-16 13:37:18 EDT
But bug 358661 has been closed, the fix for this issue has been checked into
RHEL5.2. Please update to that update release.  Can I close this one as 
CLOSE CURRENTRELEASE?
Comment 6 Axel Thimm 2008-06-16 14:33:04 EDT
Yes, thanks for the info, it doesn't need to be more than that.
Comment 7 Linda Wang 2008-07-18 00:42:46 EDT
Per comment#6. Close the bug as CURRENTRELEASE.

Thanks.

Note You need to log in before you can comment on or make changes to this bug.