qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 15/19] nbd/server: use errp instead of LOG


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH 15/19] nbd/server: use errp instead of LOG
Date: Mon, 5 Jun 2017 09:33:53 +0000


On 04.06.2017 00:46, Eric Blake wrote:
> On 05/30/2017 09:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Move to modern errp scheme from just LOGging errors.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>> ---
>>   nbd/server.c | 257 
>> ++++++++++++++++++++++++++++++++++-------------------------
>>   1 file changed, 150 insertions(+), 107 deletions(-)
>>
>> @@ -143,30 +143,30 @@ static int nbd_negotiate_send_rep_len(QIOChannel *ioc, 
>> uint32_t type,
>>             type, opt, len);
>>   
>>       magic = cpu_to_be64(NBD_REP_MAGIC);
>> -    ret = write_sync(ioc, &magic, sizeof(magic), NULL);
>> +    ret = write_sync(ioc, &magic, sizeof(magic), errp);
>>       if (ret < 0) {
>> -        LOG("write failed (rep magic)");
>> +        error_prepend(errp, "write failed (rep magic): ");
>>           return ret;
>>       }
> I'm wondering how much we really want to use error_prepend(), or if we
> could just get away with using the original error message unchanged.
> I'm not saying to rewrite the patch now that you've done the work, so
> much as asking aloud whether the additional information in the error
> messages will prove useful.
>
> There are definitely some ripple effects from your v2 posting of the
> first half of the series that will require you to rebase this, but the
> overall idea is sound.

I've tried to save old messages as is (+ additional info)

>
>>   /* Send an error reply.
>>    * Return -errno on error, 0 on success. */
>> -static int GCC_FMT_ATTR(4, 5)
>> +static int GCC_FMT_ATTR(5, 6)
>>   nbd_negotiate_send_rep_err(QIOChannel *ioc, uint32_t type,
>> -                           uint32_t opt, const char *fmt, ...)
>> +                           uint32_t opt, Error **errp, const char *fmt, ...)
> Having errp not be the last argument is unusual, but I don't see how you
> can do any differently with the var-args nature of the call.
>
>> @@ -505,26 +515,33 @@ static int nbd_negotiate_options(NBDClient *client)
>>                    * disconnecting, but that we must also tolerate
>>                    * guests that don't wait for our reply. */
>>                   ret = nbd_negotiate_send_rep(client->ioc, NBD_REP_ACK,
>> -                                             clientflags);
>> -                return ret < 0 && ret != -EPIPE ? ret : 1;
>> +                                             clientflags, &local_err);
>> +
>> +                if (ret < 0 && ret != -EPIPE) {
>> +                    error_propagate(errp, local_err);
>> +                    return ret;
>> +                }
>> +
>> +                error_free(local_err);
>> +                return 1;
> Of course, you'll have to simplify this portion.  This is probably the
> one place where you actually DO want to use:
>
> nbd_negotiate_send_rep(client->ioc, NBD_REP_ACK,
>                         clientflags, NULL)
>
> because you truly do not care whether you had an error.
>
>> @@ -1090,18 +1113,18 @@ static int nbd_co_receive_request(NBDRequestData 
>> *req, NBDRequest *request)
>>   
>>       /* Sanity checks, part 2. */
>>       if (request->from + request->len > client->exp->size) {
>> -        LOG("operation past EOF; From: %" PRIu64 ", Len: %" PRIu32
>> -            ", Size: %" PRIu64, request->from, request->len,
>> -            (uint64_t)client->exp->size);
>> +        error_setg(errp, "operation past EOF; From: %" PRIu64 ", Len: %" 
>> PRIu32
>> +                   ", Size: %" PRIu64, request->from, request->len,
>> +                   (uint64_t)client->exp->size);
>>           return request->type == NBD_CMD_WRITE ? -ENOSPC : -EINVAL;
> Question - now that we are consistently setting a decent errp, do we
> have any callers that care about specific -errno return values, or could
> we further simplify the functions by just returning -1 (instead of
> worrying about -errno) on failures?

I think it is not bad to have informative error codes.. Example is 
previous discussion about EPIPE.

>
>
>> @@ -1244,21 +1268,33 @@ static coroutine_fn void nbd_trip(void *opaque)
>>   
>>   reply:
>> +    if (local_err) {
>> +        error_report_err(local_err);
>> +        local_err = NULL;
>> +    }
> This says that after we detect an error, we report it,
>
>> +
>> +    if (nbd_co_send_reply(req, &reply, reply_data_len) < 0) {
>> +        error_setg(&local_err, "Failed to send reply");
>> +        goto disconnect;
>> +    }
> ...but then blindly try to send the reply anyways, forgetting that we
> ever detected the original error.  Is that going to bite us?

Reported error is blk_* error, which should be returned to client. But I 
think it is not bad to report is on server too (and this corresponds to 
the old behavior). Creating extra "Error *blk_err" may help.

>

-- 
Best regards,
Vladimir.




reply via email to

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