http://defect.opensolaris.org/bz/show_bug.cgi?id=6449
Summary: holding an adaptive mutex across P-state change requests
can be dangerous
Classification: Development
Product: power-mgmt
Version: unspecified
Platform: Other
OS/Version: Solaris
Status: ACCEPTED
Severity: minor
Priority: P2
Component: PAD
AssignedTo: eric.saxe at sun.com
ReportedBy: eric.saxe at sun.com
CC: tesla-dev at opensolaris.org
As part of making a power state transition (e.g. P-state transition),
cpupm_state_change() grabs an adaptive lock in the cpupm_state_domains_t
structure. Because this platform routine can be invoked out of dispatcher
context (operating at DISP_LEVEL), it can not permitted to block...otherwise
recursive dispatcher entry could happen, where the kernel would quickly panic.
I'm actually fairly surprised we haven't hit this yet. Because these locks
exist on a per power domain basis, it must be the case that the lock is fairly
non-contended (which is very good). The events which initiate P-state
transitions in event-mode are generated around atomically maintained
thresholds, so this has probably serialized things enough so that we've been
lucky. Nonetheless, this mutex should really be a MUTEX_SPIN type, since we
cannot yield the CPU.
Maintaining DISP_LEVEL while holding the mutex will be sufficient. Higher
levels (that would block out receipt of X_CALL_HIPRI) xcalls would be
dangerous, since we could lose a race getting the lock trying to send a xcall
for a P-state change, but never allow the owner of the lock to proceed with
dropping it should the owner be trying to xcall us simultaneously at
X_CALL_HIPRI.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
