qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "“William Roche" <william.roche@oracle.com>
Cc: david@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com,
	philmd@linaro.org
Subject: Re: [PATCH 1/1] system/physmem: take into account fd_offset for file fallocate
Date: Tue, 21 Jan 2025 13:17:54 -0500	[thread overview]
Message-ID: <Z4_k0u7Gdv5OKa3S@x1n> (raw)
In-Reply-To: <20250121175956.3030149-2-william.roche@oracle.com>

On Tue, Jan 21, 2025 at 05:59:56PM +0000, “William Roche wrote:
> From: William Roche <william.roche@oracle.com>
> 
> Punching a hole in a file with fallocate needs to take into account the
> fd_offset value for a correct file location.
> 
> Fixes: 4b870dc4d0c0 ("hostmem-file: add offset option")
> 
> Signed-off-by: William Roche <william.roche@oracle.com>
> ---
>  system/physmem.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/system/physmem.c b/system/physmem.c
> index c76503aea8..687ca94875 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -3689,18 +3689,20 @@ int ram_block_discard_range(RAMBlock *rb, uint64_t start, size_t length)
>              }
>  
>              ret = fallocate(rb->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
> -                            start, length);
> +                            start + rb->fd_offset, length);
>              if (ret) {
>                  ret = -errno;
>                  error_report("%s: Failed to fallocate %s:%" PRIx64 " +%zx (%d)",
> -                             __func__, rb->idstr, start, length, ret);
> +                             __func__, rb->idstr, start + rb->fd_offset, length,
> +                             ret);
>                  goto err;
>              }
>  #else
>              ret = -ENOSYS;
>              error_report("%s: fallocate not available/file"
>                           "%s:%" PRIx64 " +%zx (%d)",
> -                         __func__, rb->idstr, start, length, ret);
> +                         __func__, rb->idstr, start + rb->fd_offset, length,
> +                         ret);
>              goto err;
>  #endif
>          }

We do have plenty of fd_offset bugs then.. this makes sense to me. Nitpick
is we could use a var to cache the total offset.

> @@ -3748,17 +3750,17 @@ int ram_block_discard_guest_memfd_range(RAMBlock *rb, uint64_t start,
>  
>  #ifdef CONFIG_FALLOCATE_PUNCH_HOLE
>      ret = fallocate(rb->guest_memfd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
> -                    start, length);
> +                    start + rb->offset, length);
>  
>      if (ret) {
>          ret = -errno;
>          error_report("%s: Failed to fallocate %s:%" PRIx64 " +%zx (%d)",
> -                     __func__, rb->idstr, start, length, ret);
> +                     __func__, rb->idstr, start + rb->fd_offset, length, ret);
>      }
>  #else
>      ret = -ENOSYS;
>      error_report("%s: fallocate not available %s:%" PRIx64 " +%zx (%d)",
> -                 __func__, rb->idstr, start, length, ret);
> +                 __func__, rb->idstr, start + rb->fd_offset, length, ret);
>  #endif

IIUC the offset doesn't apply to gmemfd, see:

        new_block->guest_memfd = kvm_create_guest_memfd(new_block->max_length,
                                                        0, errp);

So my understanding is no matter how the host offset was specified, it
ignores it at least in the qemu gmemfd code to always offset from 0, which
makes sense to me, as gmemfd is anonymous anyway, and can be created more
than one for each VM, so I don't yet see why a gmemfd needs an offset indeed.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2025-01-21 18:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-21 17:59 [PATCH 0/1] fallocate missing fd_offset “William Roche
2025-01-21 17:59 ` [PATCH 1/1] system/physmem: take into account fd_offset for file fallocate “William Roche
2025-01-21 18:17   ` Peter Xu [this message]
2025-01-21 18:25     ` David Hildenbrand
2025-01-21 18:38       ` William Roche
2025-01-21 18:42         ` David Hildenbrand

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=Z4_k0u7Gdv5OKa3S@x1n \
    --to=peterx@redhat.com \
    --cc=david@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=william.roche@oracle.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).