[IA64] entry.S: perfmon psr.pp fix
Problem: There exists a case where we stop monitoring, i.e. clear psr.pp/dcr.pp, via IPI. This is when the stop is triggered by a close(), either explicit in the application or implicit via exit_files(). The IPI is necessary because at the time the thread (controlling the context) issues a close() it may not run on the CPU the context is bound to. Yet the call must succeed, hence we need to propagate the call to the right CPU. But what is the problem then? Under IPI, we invoke a perfmon routine which clear the kernel (live) kernel psr.pp bit and also dcr.pp. Then we return from the function and execute the kernel exit path which restores the interrupted state. Unfortunately, this restores the kernel psr from ipsr which now contains a stale value. Therefore monitoring in the kernel will be active even though we stopped it. You cannot modify the "global" psr in an interrupt routine because it will be systematically restored on the way back. Solution: We need to patch ipsr.pp in the kernel exit path to reflect the kernel value of the kernel psr.pp bit. This must be done only when returning to kernel. The proposed patch does patch ipsr.pp such that it is identical to psr.pp. The patch is subtle because the exit path does not have a lot of free registers and also because we need to schedule for a psr read. I had to shuffle things around a little bit. The patch is important because there will be another situation where this problem can occur once we incorporate the support for event set and multiplexing. In this configuration, you may be in the middle of the idle loop and on a timer interrupt, you may stop monitoring. Slightly different condition, yet same problem with ipsr.pp vs. psr.pp. Changelog: - update kernel exit path when returning to kernel to copy psr.pp to ipsr.pp. This is necesary to ensure that if psr.pp was modified during the kernel entry, the change is propagated the the psr.pp of the of the interrupted thread. Psr.pp can be modified as a consequence of an IPI under certain conditions, such as when a system-wide context is closed from a remote CPU. Special thanks to David for reworking the patch to fit into the enhanced exit path. signed-off-by: stephane eranian <eranian@hpl.hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Showing
Please register or sign in to comment