diff options
| author | ZhaoJinming <zhaojinming@uniontech.com> | 2026-08-05 07:43:09 +0800 |
|---|---|---|
| committer | Joerg Roedel <joerg.roedel@amd.com> | 2026-08-10 10:04:08 +0200 |
| commit | d9ef887fb26c8a73c904b5aed93e82dca64fe109 (patch) | |
| tree | e9be241c940ceb971d2d1218b1e6aef0f04e25f1 /tools/perf/scripts | |
| parent | 5b3ba0a002672d189fd55eaafdd4f55e5c6c522b (diff) | |
iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables
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.
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Diffstat (limited to 'tools/perf/scripts')
0 files changed, 0 insertions, 0 deletions
