Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] The global pointer `hv_iommu_device` is left pointing to freed memory on initialization error paths. --
commit cabf0b0a28725bbdf8a09d64a7c284187b9174dc Author: Yu Zhang <[email protected]> iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest This commit introduces a para-virtualized IOMMU driver for Linux guests on Hyper-V. It implements stage-1 IO translation within the guest OS by utilizing Hyper-V hypercalls. > diff --git a/drivers/iommu/hyperv/hv-iommu-guest.c > b/drivers/iommu/hyperv/hv-iommu-guest.c > new file mode 100644 > index 0000000000000..137f232d74fe5 > --- /dev/null > +++ b/drivers/iommu/hyperv/hv-iommu-guest.c [ ... ] > +static void __init > +hv_init_iommu_device(struct hv_iommu_dev *hv_iommu, > + struct hv_output_get_iommu_capabilities *hv_iommu_cap) > +{ [ ... ] > + hv_iommu_device = hv_iommu; > +} > + > +int __init hv_iommu_init(void) > +{ [ ... ] > + hv_iommu = kzalloc_obj(*hv_iommu, GFP_KERNEL); > + if (!hv_iommu) > + return -ENOMEM; > + > + hv_init_iommu_device(hv_iommu, &hv_iommu_cap); > + > + ret = hv_initialize_static_domains(); > + if (ret) > + goto err_free; [ ... ] > +err_free: > + kfree(hv_iommu); [Severity: Low] If hv_iommu_init() fails after calling hv_init_iommu_device(), the allocated memory is freed here on the err_free path. Does the global pointer hv_iommu_device need to be reset to NULL to avoid leaving a dangling pointer? While this might currently be unreachable because functions using hv_iommu_device are invoked via callbacks that are only registered on successful init, could this pose a regression risk for future code accessing this global state? > + return ret; > +} -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
