From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glibc-bugs-return-9047-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Received: (qmail 21457 invoked by alias); 27 Dec 2008 03:53:03 -0000
Received: (qmail 21371 invoked by uid 48); 27 Dec 2008 03:51:51 -0000
Date: Sat, 27 Dec 2008 03:53:00 -0000
From: "vapier at gentoo dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Message-ID: <20081227035150.9685.vapier@gentoo.org>
Reply-To: sourceware-bugzilla@sourceware.org
Subject: [Bug libc/9685] New: __have_{sock_cloexec,pipe2} checks not valid with linux headers older than 2.6.27
X-Bugzilla-Reason: CC
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
X-SW-Source: 2008-12/txt/msg00108.txt.bz2

if you build glibc-2.9 against kernel headers older than 2.6.27, then the
resulting libc code can easily break when running on a kernel 2.6.27 or newer. 
for example, this simple code will result in popen() failing with ENOSYS:

#include <grp.h>
#include <stdio.h>
main()
{
    getgrnam("root");
    if (!popen("ls", "r"))
        perror("popen()");
}

this is because __have_pipe2 is defined to __have_sock_cloexec in
include/unistd.h.  sock_cloexec is tested at runtime using defines that are
completely contained within glibc and so works properly regardless of the
version of kernel headers built against and the kernel version run on.  pipe2
however requires __NR_pipe2 to be defined in the kernel headers otherwise glibc
creates an ENOSYS stub for it.

so in the previous example, if we run on linux-2.6.27 or newer, getgrnam()
recurses into socket() with SOCK_CLOEXEC and detects that it works, and so it
sets __have_sock_cloexec to 1.  but when we call popen(), it sees that
__have_pipe2 is set to 1 (since it is defined to __have_sock_cloexec), and so
only calls pipe2() (which is an ENOSYS stub) and things fail.

if we give __have_pipe2 dedicated storage, then things work properly --
SOCK_CLOEXEC is detected independent of pipe2().

i wrote a patch here, but i imagine drepper will simply say it's "wrong" and do
whatever else, so no point in writing a ChangeLog/etc...
http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.9/1095_all_glibc-2.9-assume-pipe2.patch?rev=1.1

-- 
           Summary: __have_{sock_cloexec,pipe2} checks not valid with linux
                    headers older than 2.6.27
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: vapier at gentoo dot org
                CC: glibc-bugs at sources dot redhat dot com,toolchain at
                    gentoo dot org


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

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