[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121008220532.GD15039@rhmail.home.annexia.org>
Date: Mon, 8 Oct 2012 23:05:32 +0100
From: "Richard W.M. Jones" <rjones@...hat.com>
To: Jim Meyering <jim@...ering.net>, eblake@...hat.com
Cc: Al Viro <viro@...iv.linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>
Subject: F_DUPFD_CLOEXEC broken in 3.7.0
Let's move this to LKML ...
On Mon, Oct 08, 2012 at 10:53:25PM +0100, Richard W.M. Jones wrote:
> On Mon, Oct 08, 2012 at 10:50:30PM +0100, Richard W.M. Jones wrote:
> [.. discussion on gnulib test-cloexec test snipped ..]
> > I'm suspicious this is a kernel bug:
> >
> > creat("test-cloexec.tmp", 0600) = 3
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> > fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> > fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> > fcntl(3, F_SETFD, 0) = 0
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_DUPFD_CLOEXEC, 0) = 4
> > fcntl(4, F_GETFD) = 0
> > write(2, "test-cloexec.c:97: assertion failed\n", 36) = 36
> >
> > It seems to me from the description in the man page that
> > F_DUPFD_CLOEXEC ought to be setting the FD_CLOEXEC flag on file
> > descriptor 4, so either it's not or else F_GETFD isn't reading the
> > flag for some reason.
>
> Al Viro (CC'd) made some changes in this area recently ..
Attached is a self-contained test program that demonstrates the bug.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
View attachment "cloexec.c" of type "text/plain" (579 bytes)
Powered by blists - more mailing lists