qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alberto Faria <afaria@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	Fam Zheng <fam@euphon.net>, Jeff Cody <codyprime@gmail.com>
Subject: Re: [PATCH 3/7] block: Make bdrv_{pread, pwrite}() return 0 on success
Date: Fri, 13 May 2022 10:22:31 +0200	[thread overview]
Message-ID: <9541f3e7-fa0a-0f05-e5db-18be833f997a@redhat.com> (raw)
In-Reply-To: <20220512233849.2219275-4-afaria@redhat.com>

On 5/13/22 01:38, Alberto Faria wrote:
> 
> @@ -113,7 +113,7 @@ static ssize_t qcow2_crypto_hdr_read_func(QCryptoBlock *block, size_t offset,
>          error_setg_errno(errp, -ret, "Could not read encryption header");
>          return -1;
>      }
> -    return ret;
> +    return buflen;
>  }
>  
>  
> @@ -174,7 +174,7 @@ static ssize_t qcow2_crypto_hdr_write_func(QCryptoBlock *block, size_t offset,
>          error_setg_errno(errp, -ret, "Could not read encryption header");
>          return -1;
>      }
> -    return ret;
> +    return buflen;
>  }
>  
>  static QDict*

As a follow-up you could change the calling convention of readfunc and 
writefunc in crypto/block-luks.c and crypto/block-qcow.c.

More in general, crypto/block-luks.c and crypto/block-qcow.c should be 
annotated for coroutine_fn.  Let's put it on the todo list.

> @@ -88,6 +88,7 @@ static int vhdx_log_peek_hdr(BlockDriverState *bs, VHDXLogEntries *log,
>      if (ret < 0) {
>          goto exit;
>      }
> +    ret = sizeof(VHDXLogEntryHeader);
>      vhdx_log_entry_hdr_le_import(hdr);
>  
>  exit:

The callers only check the return code of vhdx_log_peek_hdr, 
vhdx_log_read_sectors, vhdx_log_write_sectors with ret < 0.  But looking 
at the callers:

- vhdx_log_read_desc propagates ret directly from a successful 
vhdx_log_read_sectors, but its callers don't care about which 
nonnegative result is returned

- vhdx_validate_log_entry might occasionally return ret directly from a 
successful vhdx_log_read_desc or vhdx_log_read_sectors, but 
vhdx_log_search, the caller of vhdx_validate_log_entry, also doesn't 
care about which nonnegative result is returned

- vhdx_log_flush only returns a successful return value from bdrv_flush

- vhdx_log_write propagates ret directly from a successful 
vhdx_log_write_sectors, but vhdx_log_write_and_flush only returns a 
successful return value from vhdx_log_flush

So (perhaps as a separate patch?) you can remove the three assignments 
of ret.


A possible cleanup is missing in vdi_co_pwritev:

>         ret = bdrv_pwrite(bs->file, offset * SECTOR_SIZE, base,
>                           n_sectors * SECTOR_SIZE);
>     }
> 
>     return ret < 0 ? ret : 0;

ret is returned by either bdrv_pwrite or bdrv_co_writev, so it can be 
simplified to just "return ret".


As an aside, while reviewing I noticed this in qcow2_mark_dirty:

     ret = bdrv_pwrite(bs->file, offsetof(QCowHeader, 
incompatible_features),
                       &val, sizeof(val));
     if (ret < 0) {
         return ret;
     }
     ret = bdrv_flush(bs->file->bs);
     if (ret < 0) {
         return ret;
     }

I'm not sure if there are other occurrencies, perhaps you can try using 
Coccinelle to find them and change them to a bdrv_pwrite_sync.

But anyway:

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


  reply	other threads:[~2022-05-13  8:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 23:38 [PATCH 0/7] Implement bdrv_{pread, pwrite, pwrite_sync, pwrite_zeroes}() using generated_co_wrapper Alberto Faria
2022-05-12 23:38 ` [PATCH 1/7] block: Add a 'flags' param to bdrv_{pread, pwrite, pwrite_sync}() Alberto Faria
2022-05-13  7:34   ` Paolo Bonzini
2022-05-12 23:38 ` [PATCH 2/7] block: Change bdrv_{pread, pwrite, pwrite_sync}() param order Alberto Faria
2022-05-13  7:34   ` Paolo Bonzini
2022-05-12 23:38 ` [PATCH 3/7] block: Make bdrv_{pread,pwrite}() return 0 on success Alberto Faria
2022-05-13  8:22   ` Paolo Bonzini [this message]
2022-05-13 14:56     ` [PATCH 3/7] block: Make bdrv_{pread, pwrite}() " Alberto Faria
2022-05-12 23:51 ` [PATCH 4/7] block: Make bdrv_co_pwrite() take a const buffer Alberto Faria
2022-05-13  7:38   ` Paolo Bonzini
2022-05-12 23:51 ` [PATCH 5/7] block: Make 'bytes' param of bdrv_co_{pread, pwrite, preadv, pwritev}() an int64_t Alberto Faria
2022-05-13  7:39   ` Paolo Bonzini
2022-05-12 23:51 ` [PATCH 6/7] block: Implement bdrv_{pread, pwrite, pwrite_zeroes}() using generated_co_wrapper Alberto Faria
2022-05-13  7:41   ` Paolo Bonzini
2022-05-13 14:50     ` Alberto Faria
2022-05-12 23:51 ` [PATCH 7/7] block: Add bdrv_co_pwrite_sync() Alberto Faria
2022-05-13  7:34   ` Paolo Bonzini

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=9541f3e7-fa0a-0f05-e5db-18be833f997a@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaria@redhat.com \
    --cc=codyprime@gmail.com \
    --cc=fam@euphon.net \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --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).