On Wed, Nov 01, 2023 at 07:36:27PM +0200, José Pekkarinen wrote:
Hinted by syzboot, there is a few cases where the sysfs power group may
not be there, like the failure while adding it, or adding its runtime
group, or when the sysfs firmware loader fallback fail to populate. In
the last case, the device_del function will be called leading to attempt
to remove the sysfs group. This patch will lookup for it in advance to
grant that it is effectively there before cleaning it up.
Reported-by: syzbot+95f2e2439b97575ec3c0@xxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: José Pekkarinen <jose.pekkarinen@xxxxxxxxxxx>
---
drivers/base/power/sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index a1474fb67db9..6601729c4698 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -834,5 +834,7 @@ void dpm_sysfs_remove(struct device *dev)
dev_pm_qos_constraints_destroy(dev);
rpm_sysfs_remove(dev);
sysfs_unmerge_group(&dev->kobj, &pm_wakeup_attr_group);
- sysfs_remove_group(&dev->kobj, &pm_attr_group);
+
+ if (kernfs_find_and_get((&dev->kobj)->sd, pm_attr_group.name))
+ sysfs_remove_group(&dev->kobj, &pm_attr_group);
What's to keep it from going away right after finding it?
In other words, what is wrong with removing a group that is not there?
What error happens? It should be fine, or are you seeing real code
failures somewhere?
Also, I think you just leaked a reference count here, how was this
tested?