qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block/curl: Improve type safety of s->timeout.
Date: Mon, 06 Oct 2014 16:43:27 +0200	[thread overview]
Message-ID: <5432AA8F.70901@redhat.com> (raw)
In-Reply-To: <20141006144030.GN1349@redhat.com>

On 10/06/14 16:40, Richard W.M. Jones wrote:
> On Mon, Oct 06, 2014 at 04:38:59PM +0200, Laszlo Ersek wrote:
>> On 10/06/14 16:32, Richard W.M. Jones wrote:
>>> qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
>>> long (not an int).
>>>
>>> Store the timeout (which is a positive number of seconds) as a
>>> uint64_t.  Check that the number given by the user is reasonable.
>>> Cast it to long before calling curl_easy_setopt.
>>>
>>> Example error message after this change has been applied:
>>>
>>> $ ./qemu-img create -f qcow2 /tmp/test.qcow2 \
>>>     -b 'json: { "file.driver":"https",
>>>                 "file.url":"https://foo/bar",
>>>                 "file.timeout":-1 }'
>>> qemu-img: /tmp/test.qcow2: Could not open 'json: { "file.driver":"https", "file.url":"https://foo/bar", "file.timeout":-1 }': timeout parameter is too large or negative: Invalid argument
>>>
>>> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
>>> ---
>>>  block/curl.c | 8 ++++++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/block/curl.c b/block/curl.c
>>> index 225407c..5233ff6 100644
>>> --- a/block/curl.c
>>> +++ b/block/curl.c
>>> @@ -112,7 +112,7 @@ typedef struct BDRVCURLState {
>>>      char *url;
>>>      size_t readahead_size;
>>>      bool sslverify;
>>> -    int timeout;
>>> +    uint64_t timeout;
>>>      char *cookie;
>>>      bool accept_range;
>>>      AioContext *aio_context;
>>> @@ -390,7 +390,7 @@ static CURLState *curl_init_state(BlockDriverState *bs, BDRVCURLState *s)
>>>          if (s->cookie) {
>>>              curl_easy_setopt(state->curl, CURLOPT_COOKIE, s->cookie);
>>>          }
>>> -        curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, s->timeout);
>>> +        curl_easy_setopt(state->curl, CURLOPT_TIMEOUT, (long)s->timeout);
>>>          curl_easy_setopt(state->curl, CURLOPT_WRITEFUNCTION,
>>>                           (void *)curl_read_cb);
>>>          curl_easy_setopt(state->curl, CURLOPT_WRITEDATA, (void *)state);
>>> @@ -546,6 +546,10 @@ static int curl_open(BlockDriverState *bs, QDict *options, int flags,
>>>  
>>>      s->timeout = qemu_opt_get_number(opts, CURL_BLOCK_OPT_TIMEOUT,
>>>                                       CURL_TIMEOUT_DEFAULT);
>>> +    if (s->timeout > 100000) {
>>> +        error_setg(errp, "timeout parameter is too large or negative");
>>> +        goto out_noclean;
>>> +    }
>>>  
>>>      s->sslverify = qemu_opt_get_bool(opts, CURL_BLOCK_OPT_SSLVERIFY, true);
>>>  
>>>
>>
>> Since we're validating s->timeout -- is a zero value okay?
> 
> Yes it's OK.  It means wait forever:
> 
>        CURLOPT_TIMEOUT
>               Pass a long as parameter containing the maximum time in  seconds
>               that you allow the libcurl transfer operation to take. Normally,
>               name lookups can take a considerable time  and  limiting  opera‐
>               tions  to less than a few minutes risk aborting perfectly normal
>               operations. This option will cause curl to use  the  SIGALRM  to
>               enable time-outing system calls.
> 
>               In unix-like systems, this might cause signals to be used unless
>               CURLOPT_NOSIGNAL is set.
> 
>               Default timeout is 0 (zero) which means it never times out.
> 
> Rich.
> 

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

  reply	other threads:[~2014-10-06 14:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06 14:32 [Qemu-devel] [PATCH] block/curl: Improve type safety of s->timeout Richard W.M. Jones
2014-10-06 14:38 ` Laszlo Ersek
2014-10-06 14:40   ` Richard W.M. Jones
2014-10-06 14:43     ` Laszlo Ersek [this message]
2014-10-28 14:29 ` Stefan Hajnoczi
2014-10-29  2:08   ` Gonglei
2014-10-29  9:52     ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5432AA8F.70901@redhat.com \
    --to=lersek@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).