qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] semihosting: split console_out intro string


From: Alex Bennée
Subject: Re: [Qemu-devel] [RFC PATCH] semihosting: split console_out intro string and char versions
Date: Fri, 31 May 2019 09:30:23 +0100
User-agent: mu4e 1.3.2; emacs 26.1

Laurent Vivier <address@hidden> writes:

> Le 30/05/2019 à 16:39, Alex Bennée a écrit :
>> This is ostensibly to avoid the weirdness of len looking like it might
>> come from a guest and sometimes being used. While we are at it fix up
>> the error checking for the arm-linux-user implementation of the API
>> which got flagged up by Coverity (CID 1401700).
>>
>> Signed-off-by: Alex Bennée <address@hidden>
>> ---
<snip>
>>  /**
>>   * qemu_semihosting_log_out:
>> diff --git a/linux-user/arm/semihost.c b/linux-user/arm/semihost.c
>> index 9554102a855..b7cdc21f832 100644
>> --- a/linux-user/arm/semihost.c
>> +++ b/linux-user/arm/semihost.c
>> @@ -15,10 +15,34 @@
>>  #include "hw/semihosting/console.h"
>>  #include "qemu.h"
>>
>> -int qemu_semihosting_console_out(CPUArchState *env, target_ulong addr, int 
>> len)
>> +int qemu_semihosting_console_outs(CPUArchState *env, target_ulong addr)
>>  {
>> +    int len;
>>      void *s = lock_user_string(addr);
>> -    len = write(STDERR_FILENO, s, len ? len : strlen(s));
>> +    if (!s) {
>> +        qemu_log_mask(LOG_GUEST_ERROR,
>> +                      "%s: passed inaccessible address " TARGET_FMT_lx,
>> +                      __func__, addr);
>> +        return 0;
>> +    }
>> +
>> +    len = write(STDERR_FILENO, s, strlen(s));
>
> You could avoid 2 calls to strlen() if you inline directly
> lock_user_string() content:
>
>     len = target_strlen(addr);
>     if (len < 0){
>        qemu_log_mask(LOG_GUEST_ERROR,
>                      "%s: passed inaccessible address " TARGET_FMT_lx,
>                      __func__, addr);
>        return 0;
>     }
>     s = lock_user(VERIFY_READ, addr, (long)(len + 1), 1);
>     len = write(STDERR_FILENO, s, len);
>
>>      unlock_user(s, addr, 0);
>>      return len;
>>  }

It's a nice clean-up but I've just looked at what was going on inside
with lock_user. I guess g_assert(s) on the lock user would be fair as we
can't fail at this point?

--
Alex Bennée



reply via email to

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