qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] syscall: fix special case of write(fd, NULL, 0)


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] syscall: fix special case of write(fd, NULL, 0)
Date: Fri, 29 Sep 2017 12:49:08 -0700

On 29 September 2017 at 12:14, Laurent Vivier <address@hidden> wrote:
> Le 29/09/2017 à 18:50, address@hidden a écrit :
>> From: Zhuowei Zhang <address@hidden>
>>
>> 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.
>>
>> Signed-off-by: Zhuowei Zhang <address@hidden>
>> ---
>>  linux-user/syscall.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 9b6364a..ecadf49 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -7783,6 +7783,11 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
>> arg1,
>>          }
>>          break;
>>      case TARGET_NR_write:
>> +        if (arg2 == 0 && arg3 == 0) {
>> +            /* special case: write(fd, NULL, 0) returns success. */
>> +            ret = 0;
>> +            break;
>> +        }
>>          if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
>>              goto efault;
>>          if (fd_trans_target_to_host_data(arg1)) {
>>
>
> I think we should keep the call to the kernel write() as the behavior
> depends on the driver behind the syscall. Moreover, calling write() with
> (NULL, 0) can triggers "something" at kernel level.

I tend to agree. On the other hand our handling of NR_read
with a zero count just returns 0 without calling the syscall;
perhaps we should change that for consistency?

Do we also have the same issue with pread64/pwrite64 ?

thanks
-- PMM



reply via email to

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