Re: [PATCH v2] iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables

On 7/27/26 13:22, ZhaoJinming wrote:
> The iommu->copied_tables bitmap was introduced by the IOMMU live
> update series to track which context entries have been copied from
> the previous kernel.  The allocation via bitmap_zalloc() was added
> inside copy_translation_tables(), but the error paths were not
> updated to free it:
> 
>    1. When old_rt_phys is 0 (invalid root table address)
>    2. When memremap(old_rt_phys) fails
>    3. When kcalloc for ctxt_tbls fails (goto out_unmap, which only
>       unmaps old_rt without releasing the bitmap)
> 
> The bitmap is only cleaned up by free_dmar_iommu(), which is
> called from the free_iommu error label in init_dmars().  However,
> when copy_translation_tables() fails, init_dmars() does not jump
> to free_iommu -- it logs the error, falls through, and continues
> with the next IOMMU.  As a result, copied_tables is leaked.
> 
> Fix this by converting the two early returns to goto a new
> err_free_bitmap label, and by making out_unmap fall through to
> it so that the bitmap is always freed on any error path.  The
> success path performs memunmap(old_rt) inline and returns 0
> directly, since copied_tables must remain allocated for
> subsequent use.
> ---
> 
> v2:
> - On the success path, call memunmap(old_rt) before returning 0
>    instead of returning directly, fixing a memunmap leak introduced
>    in v1.  Suggested by Baolu Lu.
> 
> Signed-off-by: ZhaoJinming<[email protected]>

Your signed-off-by should be placed above the "---" line.

> ---
>   drivers/iommu/intel/iommu.c | 19 +++++++++++++------
>   1 file changed, 13 insertions(+), 6 deletions(-)

Queued for iommu/next with the above change applied manually.

Thanks,
baolu