Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Use-after-free of BO label string in debugfs due to incorrect cleanup ordering -- commit a176b75fb18c68d91dd9610fff6763a62e825a4f Author: Adrián Larumbe <[email protected]> drm/panfrost: Move debugfs initialisation to relevant subsystems This commit moves the initialization of debugfs knobs out of panfrost_drv.c and into the specific subsystems they provide information about, such as gem and sched. > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c > b/drivers/gpu/drm/panfrost/panfrost_gem.c > index 383ac8cd56456..518f24549b9de 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c [ ... ] > @@ -756,4 +757,28 @@ void panfrost_gem_debugfs_print_bos(struct > panfrost_device *pfdev, > seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: > %zd\n", > totals.size, totals.resident, totals.reclaimable); > } > + > +static int panfrost_gems_show(struct seq_file *m, void *data) > +{ > + struct drm_info_node *node = m->private; > + struct panfrost_device *pfdev = to_panfrost_device(node->minor->dev); > + > + panfrost_gem_debugfs_print_bos(pfdev, m); [Severity: High] This is a pre-existing issue, but does this debugfs read path have a race condition with BO destruction that could lead to a use-after-free? When reading the gems debugfs file, panfrost_gem_debugfs_print_bos() holds the gems_lock and iterates over BOs. If it reads a positive refcount for a BO, and immediately after that the last reference to the BO is dropped by another thread, panfrost_gem_free_object() in drivers/gpu/drm/panfrost/panfrost_gem.c is called. In panfrost_gem_free_object(), the cleanup order frees the label string before removing the BO from the debugfs list: panfrost_gem_free_object() ... kfree_const(bo->label.str); panfrost_gem_debugfs_bo_rm(bo); mutex_destroy(&bo->label.lock); Because the string is freed before the BO is removed from the debugfs list and before synchronization on the list lock occurs in panfrost_gem_debugfs_bo_rm(), the debugfs printing thread could dereference the freed bo->label.str. Should panfrost_gem_debugfs_bo_rm(bo) be called before freeing the string and destroying the lock to prevent this? > + > + return 0; > +} -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
