O_CLOEXEC not handled in dup3 system call in user mode

[Bruno Haible]

In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag.

When the attached program runs, the expected output is:
errno=9=EBADF

How to reproduce on hppa:
- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa
- Set environment variables for running qemu-hppa.
- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed

How to reproduce on sparc64:
- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64
- Set environment variables for running qemu-sparc64.
- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed

[Bruno Haible (bruno-clisp)]

I see this bug for hppa, sparc64.
I don't see it for m68k, mips, mips64, powerpc, powerpc64.
Most likely because the binary values of O_CLOEXEC on hppa and sparc64 are different than on other platforms. Looking in the glibc source code:

$ grep -r 'define.*O_CLOEXEC' glibc
glibc/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set close_on_exec. */
glibc/sysdeps/mach/hurd/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set FD_CLOEXEC. */
glibc/sysdeps/unix/sysv/linux/sparc/bits/fcntl.h:#define __O_CLOEXEC 0x400000 /* Set close_on_exit. */
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define __O_CLOEXEC 02000000
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define O_CLOEXEC __O_CLOEXEC /* Set close_on_exec. */
glibc/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h:#define __O_CLOEXEC 010000000 /* Set close_on_exec. */
glibc/sysdeps/unix/sysv/linux/microblaze/bits/fcntl.h:#define __O_CLOEXEC 02000000 /* Set close_on_exec. */
glibc/sysdeps/unix/sysv/linux/alpha/bits/fcntl.h:#define __O_CLOEXEC 010000000 /* Set close_on_exec. */
glibc/sysdeps/nacl/bits/fcntl.h:# define O_CLOEXEC 02000000 /* Set close_on_exec. */

So, what's missing is probably that the O_CLOEXEC of the target platform gets mapped to O_CLOEXEC of the host platform, during the dup3 system call emulation.

[Bruno Haible (bruno-clisp)]

The behaviour in qemu-2.10 is the same as in qemu-2.9.

[Bruno Haible (bruno-clisp)]

The behaviour in qemu-2.11 is the same as in qemu-2.9.

[Peter Maydell (pmaydell)]

Should be fixed by http://patchwork.ozlabs.org/patch/849226/

[Thomas Huth (th-huth)]

Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=10fa993aae539fa8d0da1d

[Bruno Haible (bruno-clisp)]

Confirmed: It's fixed in qemu-2.12.