Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] drm/pagemap: CPU stall re-introduced by unbounded drm_dbg() loop --
commit ea1ff5e58f9772cc1eaec3db21133d24e24bd4f0 Author: Varun Gupta <[email protected]> drm/pagemap: Drop ratelimiting from dev_unhold_work debug trace This commit reverts the use of drm_dbg_ratelimited back to drm_dbg in drm_pagemap_dev_unhold_work to avoid "callbacks suppressed" notifications from the kernel's ratelimiting subsystem. > diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c > index c66c58f85c345..743988036a5f8 100644 > --- a/drivers/gpu/drm/drm_pagemap.c > +++ b/drivers/gpu/drm/drm_pagemap.c > @@ -1102,7 +1102,7 @@ static void drm_pagemap_dev_unhold_work(struct > work_struct *work) > struct drm_device *drm = dev_hold->drm; > struct module *module = drm->driver->fops->owner; > > - drm_dbg_ratelimited(drm, "Releasing reference on provider > device and module.\n"); > + drm_dbg(drm, "Releasing reference on provider device and > module.\n"); [Severity: Medium] Does this code re-introduce a serial console bottleneck and potential CPU stall during teardown? When tearing down an unbounded number of DRM pagemaps, drm_pagemap_dev_unhold_work() iterates over the entire drm_pagemap_unhold_list. If DRM debugging is enabled, drm_dbg() is now called for every single entry unconditionally. If the goal is to prevent the "callbacks suppressed" warning from the ratelimiting subsystem, would it be better to drop the repetitive log entirely, or perhaps log once outside the loop, rather than reverting the CPU stall fix? > drm_dev_put(drm); > module_put(module); > kfree(dev_hold); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
