linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: lirongqing <lirongqing@baidu.com>
Cc: <kwankhede@nvidia.com>, <yan.y.zhao@intel.com>, <cjia@nvidia.com>,
	<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vfio/type1: fixed rollback in vfio_dma_bitmap_alloc_all()
Date: Wed, 21 May 2025 14:00:34 -0600	[thread overview]
Message-ID: <20250521140034.35648fde.alex.williamson@redhat.com> (raw)
In-Reply-To: <20250521034647.2877-1-lirongqing@baidu.com>

On Wed, 21 May 2025 11:46:47 +0800
lirongqing <lirongqing@baidu.com> wrote:

> From: Li RongQing <lirongqing@baidu.com>
> 
> The vfio dma bitmap of p should be freed, not n
> 
> Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
>  drivers/vfio/vfio_iommu_type1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 0ac5607..ba5d91e 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -293,7 +293,7 @@ static int vfio_dma_bitmap_alloc_all(struct vfio_iommu *iommu, size_t pgsize)
>  			struct rb_node *p;
>  
>  			for (p = rb_prev(n); p; p = rb_prev(p)) {
> -				struct vfio_dma *dma = rb_entry(n,
> +				struct vfio_dma *dma = rb_entry(p,
>  							struct vfio_dma, node);
>  
>  				vfio_dma_bitmap_free(dma);

Good find.  The change looks correct to me.  For the benefit of stable
backports, let's venture towards being overly verbose in the subject and
commit log.  My suggestion would be:

    vfio/type1: Fix error unwind in migration dirty bitmap allocation

    When setting up dirty page tracking at the vfio IOMMU backend for
    device migration, if an error is encountered allocating a tracking
    bitmap, the unwind loop fails to free previously allocated tracking
    bitmaps.  This occurs because the wrong loop index is used to
    generate the tracking object.  This results in unintended memory
    usage for the life of the current DMA mappings where bitmaps were
    successfully allocated.

    Use the correct loop index to derive the tracking object for
    freeing during unwind.

This gives us some context relative to when we might encounter this
issue (pretty rare) and the scope of the issue (bound to the lifetime
of the vfio_dma object).  If you approve I can incorporate this to v1
or feel free to send a v2 with these updates.  Thanks,

Alex


  reply	other threads:[~2025-05-21 20:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  3:46 [PATCH] vfio/type1: fixed rollback in vfio_dma_bitmap_alloc_all() lirongqing
2025-05-21 20:00 ` Alex Williamson [this message]
2025-05-22  1:53   ` 答复: [????] " Li,Rongqing
2025-05-22 17:52     ` Alex Williamson

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=20250521140034.35648fde.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=yan.y.zhao@intel.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).