Hi Zhao,
I ran into the iommu_group leak independently today - Sashiko flagged
it again on my rocket clks fix [1] - and before writing anything I
went through the lists and found your series, so let me try to help
here rather than duplicate it.
I read v6 2/2 and the review history, and I think the patch got stuck
because it bundles two separate things:
(a) the iommu_group leak in rocket_job_handle_irq(). Your fix for
this is exactly right: reusing the cached core->iommu_group
matches what rocket_job_run() and rocket_reset() already do, and
rocket_core_init() sets up the cache before the IRQ handler can
run and only puts it in rocket_core_fini(). That part is a clean
one-liner with Fixes: 0810d5ad88a1.
(b) the runtime-PM guards around the IRQ register accesses - which is
where each revision drew new review comments.
Would you consider respinning just (a) as a standalone v7? I would be
glad to test it on RK3588 (Orange Pi 5 Plus) and reply with Tested-by:
I have a benchmark here that exercises exactly that line ~150 times
per second with bit-exact output verification. (b) can then be
discussed separately without holding the simple fix hostage.
For what it is worth regarding the AI review noise: the leak is real
but bounded - it happens once per job (the intermediate-task IRQs
return before that line), and the group kobject kref saturates with a
one-time WARN rather than overflowing - and the one-line fix cannot
regress the NULL-group case either, since it passes the same value the
current code already passes. So (a) stands on its own merits.
[1]
https://lore.kernel.org/linux-rockchip/[email protected]/
Thanks,
Igor Paunovic
