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
next prev parent 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).