From 48986b3b23f610c7e8bf9b1dec244bf7b604ff25 Mon Sep 17 00:00:00 2001 From: Tony Garnock-Jones Date: Fri, 7 Sep 2018 12:39:23 +0100 Subject: [PATCH] Bring linux-user write(2) handling into line with linux for the case of a 0-byte write with a NULL buffer. Based on a patch originally written by Zhuowei Zhang. Addresses https://bugs.launchpad.net/qemu/+bug/1716292. From Zhuowei Zhang's patch (https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg08073.html): Linux returns success for the special case of calling write with a zero-length NULL buffer: compiling and running int main() { ssize_t ret = write(STDOUT_FILENO, NULL, 0); fprintf(stderr, "write returned %ld\n", ret); return 0; } gives "write returned 0" when run directly, but "write returned -1" in QEMU. This commit checks for this situation and returns success if found. Subsequent discussion raised the following questions (and my answers): - Q. Should TARGET_NR_read pass through to safe_read in this situation too? A. I'm wary of changing unrelated code to the specific problem I'm addressing. TARGET_NR_read is already consistent with Linux for this case. - Q. Do pread64/pwrite64 need to be changed similarly? A. Experiment suggests not: both linux and linux-user yield -1 for NULL 0-length reads/writes. Signed-off-by: Tony Garnock-Jones --- linux-user/syscall.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 850b72a0c7..8f46540534 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -8168,6 +8168,9 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, } return ret; case TARGET_NR_write: + if (arg2 == 0 && arg3 == 0) { + return get_errno(safe_write(arg1, 0, 0)); + } if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1))) return -TARGET_EFAULT; if (fd_trans_target_to_host_data(arg1)) { -- 2.18.0