All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH 1/1] block/crypto: better error message when creating too large files
Date: Mon, 20 Apr 2020 11:02:53 +0200	[thread overview]
Message-ID: <20200420090253.GA6237@linux.fritz.box> (raw)
In-Reply-To: <20200416095019.4406-2-mlevitsk@redhat.com>

Am 16.04.2020 um 11:50 hat Maxim Levitsky geschrieben:
> Currently if you attampt to create too large file with luks you
> get the following error message:
> 
> Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
> qemu-img: test.luks: Could not resize file: File too large
> 
> While for raw format the error message is
> qemu-img: test.img: The image size is too large for file format 'raw'
> 
> 
> The reason for this is that qemu-img checks for errno of the failure,
> and presents the later error when it is -EFBIG
> 
> However crypto generic code 'swallows' the errno and replaces it
> with -EIO.
> 
> As an attempt to make it better, we can make luks driver,
> detect -EFBIG and in this case present a better error message,
> which is what this patch does
> 
> The new error message is:
> 
> qemu-img: error creating test.luks: The requested file size is too large
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534898
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  block/crypto.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/block/crypto.c b/block/crypto.c
> index d577f89659..1b604beb30 100644
> --- a/block/crypto.c
> +++ b/block/crypto.c
> @@ -104,18 +104,35 @@ static ssize_t block_crypto_init_func(QCryptoBlock *block,
>                                        Error **errp)
>  {
>      struct BlockCryptoCreateData *data = opaque;
> +    Error *local_error = NULL;
> +    int ret;
>  
>      if (data->size > INT64_MAX || headerlen > INT64_MAX - data->size) {
> -        error_setg(errp, "The requested file size is too large");
> -        return -EFBIG;
> +        ret = -EFBIG;
> +        goto error;
>      }
>  
>      /* User provided size should reflect amount of space made
>       * available to the guest, so we must take account of that
>       * which will be used by the crypto header
>       */
> -    return blk_truncate(data->blk, data->size + headerlen, false,
> +    ret = blk_truncate(data->blk, data->size + headerlen, false,
>                          data->prealloc, errp);

I think you intended to use &local_error (which is by the way spelt
local_err in most other places) here instead of passing errp and never
assigning local_err at all.

Kevin

> +
> +    if (ret >= 0) {
> +        return ret;
> +    }
> +
> +error:
> +    if (ret == -EFBIG) {
> +        /* Replace the error message with a better one */
> +        error_free(local_error);
> +        error_setg(errp, "The requested file size is too large");
> +    } else {
> +        error_propagate(errp, local_error);
> +    }
> +
> +    return ret;
>  }
>  
>  
> -- 
> 2.17.2
> 



  reply	other threads:[~2020-04-20  9:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16  9:50 [PATCH 0/1] LUKS: Fix error message when underlying fs don't support large enough files Maxim Levitsky
2020-04-16  9:50 ` [PATCH 1/1] block/crypto: better error message when creating too large files Maxim Levitsky
2020-04-20  9:02   ` Kevin Wolf [this message]
2020-04-20  9:16     ` Maxim Levitsky
2020-04-16  9:54 ` [PATCH 0/1] LUKS: Fix error message when underlying fs don't support large enough files Maxim Levitsky

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=20200420090253.GA6237@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.