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 <tonygarnockjones@gmail.com>
---
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
[University of Glasgow: The Times Scottish University of the Year 2018]
On Sat, 8 Sep 2018 at 22:04, Tony Garnock-Jones
<tony.garnock-jones@glasgow.ac.uk> wrote:
>
> 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.
Hi; following up on this, we've just had
https://bugs.launchpad.net/qemu/+bug/1810433 which is
a report of the same NULL/0 bug for pwrite64. Looking at the
kernel code I see that both the write and pwrite64 syscalls
go through the same vfs_write() common function, so their
behaviour for NULL/0 should be identical. Experimentally,
stracing the 1810433 test program gives
pwrite64(3, NULL, 0, 0) = 0
so we do indeed need to special case NULL/0 there as well
as in write().
The extra fix should be straightforward -- does anybody
feel like writing up a patch for it?
thanks
-- PMM
On Thu, 3 Jan 2019 at 18:31, Peter Maydell <peter.maydell@linaro.org> wrote: > Hi; following up on this, we've just had > https://bugs.launchpad.net/qemu/+bug/1810433 which is > a report of the same NULL/0 bug for pwrite64. Looking at the > kernel code I see that both the write and pwrite64 syscalls > go through the same vfs_write() common function, so their > behaviour for NULL/0 should be identical. Experimentally, > stracing the 1810433 test program gives > pwrite64(3, NULL, 0, 0) = 0 > so we do indeed need to special case NULL/0 there as well > as in write(). > > The extra fix should be straightforward -- does anybody > feel like writing up a patch for it? I've just sent a patch: https://patchwork.ozlabs.org/patch/1022092/ thanks -- PMM
On Sat, Sep 8, 2018 at 6:04 PM Tony Garnock-Jones
<tony.garnock-jones@glasgow.ac.uk> wrote:
>
> 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 <tonygarnockjones@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> 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
>
>
> [University of Glasgow: The Times Scottish University of the Year 2018]
>
Le 08/09/2018 à 20:22, Tony Garnock-Jones a écrit :
> 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 <tonygarnockjones@gmail.com>
> ---
> linux-user/syscall.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
© 2016 - 2025 Red Hat, Inc.