[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) p

From: Peter Maydell
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: write(fd, NULL, 0) parity with linux's treatment of same
Date: Thu, 3 Jan 2019 18:31:13 +0000

On Sat, 8 Sep 2018 at 22:04, Tony Garnock-Jones
<address@hidden> 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?

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]