Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] sysfs: WARNING in kernfs_remove_by_name_ns due to unconditionally deleting uninitialized kobject --
commit a813e5e5e38ff926a8859f22732d8fde3e0ed689 Author: Ian Rogers <[email protected]> drm/amdkfd: Free queue in procfs_queue_type kobject release callback This commit adds a release callback to free the struct queue from the kobject release function to prevent a use-after-free, and adjusts the kobject_put() locations accordingly. > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c > b/drivers/gpu/drm/amd/amdkfd/kfd_process.c > --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c [ ... ] > @@ -701,7 +708,6 @@ void kfd_procfs_del_queue(struct queue *q) > return; > > kobject_del(&q->kobj); [Severity: Medium] Can this trigger a kernel warning if sysfs creation fails? If kfd_procfs_add_queue() fails (for example, due to a memory allocation failure in sysfs), q->kobj.state_in_sysfs remains 0 and q->kobj.sd is null. However, pqm_create_queue() may ignore this sysfs failure and keep the queue operational. Later, when pqm_destroy_queue() calls kfd_procfs_del_queue(), kobject_del() is called unconditionally. This results in a call chain to __kobject_del() which invokes sysfs_remove_groups() with a null kobj->sd. This eventually propagates to kernfs_remove_by_name_ns(), where a warning is triggered explicitly when its parent argument is null: fs/kernfs/dir.c:kernfs_remove_by_name_ns() { ... if (!parent) { WARN(1, KERN_WARNING "kernfs: can not remove '%s', no directory\n", name); return -ENOENT; } ... } Should we check if the kobject was successfully added to sysfs (such as checking q->kobj.state_in_sysfs) before calling kobject_del()? > - kobject_put(&q->kobj); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=10
