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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
