vireshk

Untitled

Jan 20th, 2016
103
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.37 KB | None | 0 0
  1. commit 57714d5b1778f2f610bcc5c74d85b29ba1cc1995
  2. Author: Viresh Kumar <viresh.kumar@linaro.org>
  3. Date: Wed Jan 21 11:31:39 2015 +0530
  4.  
  5. cpufreq: Access governor's sysfs attributes without 'policy->rwsem'
  6.  
  7. Commit 955ef4833574 ("cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT")
  8. dropped policy->rwsem because of some ABBA deadlocks.
  9.  
  10. We weren't clear about the reasoning behind the deadlocks earlier and so dropped
  11. the locks before calling CPUFREQ_GOV_POLICY_EXIT.
  12.  
  13. The actual problem was:
  14.  
  15. If we hold any locks, that the attribute operations grab, when removing the
  16. attribute, then it can result in a ABBA deadlock.
  17.  
  18. show()/store() holds the policy->rwsem lock while accessing any sysfs attributes
  19. under cpu/cpuX/cpufreq/ directory.
  20.  
  21. Consider this scenario for drivers with CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag:
  22. - Access any governor sysfs attribute. This will increment the active-count of
  23. sysfs attribute and show/store() of cpufreq core will get called. We will try
  24. to take policy->rwsem lock there, but following happens before that.
  25.  
  26. - Another thread tries to change the governor by writing to
  27. cpuX/cpufreq/scaling_governor. We took policy->rwsem lock from store() and
  28. called CPUFREQ_GOV_POLICY_EXIT for governor.
  29.  
  30. We call sysfs_remove_group() for the governor attributes, but that will wait
  31. for active-count to become zero.
  32.  
  33. Now the first thread is waiting for the policy->rwsem lock and the next one for
  34. zero active-count.
  35.  
  36. Perfect ABBA deadlock.
  37.  
  38. Proposed solution: Accessing govenors attributes doesn't require policy->rwsem
  39. lock and so avoid it.
  40.  
  41. - There are two code paths while accessing governor sysfs attributes.
  42. - Gov-per-policy: show/store() routines are called.
  43. - Common-gov: governor show/store routines called directly. In this case the
  44. governor might be getting used for multiple policies and so we couldn't take
  45. policy->rwsem lock there.
  46.  
  47. So we need to avoid the locks only for the first case.
  48.  
  49. This patch adds another field 'skip_lock' to 'struct freq_attr' and is set only
  50. for the governors. When this is set, we don't take policy->rwsem lock in
  51. show/store() routines.
  52.  
  53. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Add Comment
Please, Sign In to add comment