> -----Original Message----- > From: Hans de Goede <hdegoede@xxxxxxxxxx> > Sent: Monday, January 25, 2021 2:09 PM > > After a rmmod thinkpad_acpi, lockdep pointed out this possible deadlock: > > Our _show and _store sysfs attr functions get called with the kn->active > lock held for the sysfs attr and then take the profile_lock. > sysfs_remove_group() also takes the kn->active lock for the sysfs attr, > so if we call it with the profile_lock held, then we get an ABBA deadlock. > > platform_profile_remove() must only be called by drivers which have > first *successfully* called platform_profile_register(). Anything else > is a driver bug. So the check for cur_profile being set before calling > sysfs_remove_group() is not necessary and it can be dropped. > > It is safe to call sysfs_remove_group() without holding the profile_lock > since the attr-group group cannot be re-added until after we clear > cur_profile. > > Change platform_profile_remove() to only hold the profile_lock while > clearing the cur_profile, fixing the deadlock. > > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > --- > drivers/acpi/platform_profile.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c > index 80e9df427eb8..4a59c5993bde 100644 > --- a/drivers/acpi/platform_profile.c > +++ b/drivers/acpi/platform_profile.c > @@ -164,13 +164,9 @@ EXPORT_SYMBOL_GPL(platform_profile_register); > > int platform_profile_remove(void) > { > - mutex_lock(&profile_lock); > - if (!cur_profile) { > - mutex_unlock(&profile_lock); > - return -ENODEV; > - } > - > sysfs_remove_group(acpi_kobj, &platform_profile_group); > + > + mutex_lock(&profile_lock); > cur_profile = NULL; > mutex_unlock(&profile_lock); > return 0; > -- > 2.29.2 Thanks Hans - good catch! Looks good to me. Mark