Re: [Qemu-trivial] [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
<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?

thanks
-- PMM