On 10/08/2012 03:53 PM, 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,

Indeed, that is the behavior required by POSIX (for F_DUPFD_CLOEXEC, the
flag must be atomically set on fd 4, even though it was clear on fd 3).

> 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 ..

I concur, this sounds like a kernel regression.

-- 
Eric Blake   ebl...@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to