[Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Tony Garnock-Jones]

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]

Re: [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Laurent Vivier]

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>

Re: [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Peter Maydell]

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

Re: [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same

[Peter Maydell]

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