Hi,
By looking at the context switch code for X86, I found there is
potentially a risk of leakage between one session and anoother.
Basically, one session could pick up the pmc register
settings from a previous session running on the same CPU.
Let me explain.
For context switch in, there are two strategies:
1- restore everything
2- restore only the register we actually use
Perfmon2 uses strategy 2 for obcious performance reasons.
That means the implementation tracks register usage. A register is considered
used if it is:
- written to via pfm_write_pmcs or pfm_write_pmds
- specified in the reg_smpl_reset or reg_smpl_pmds of a PMDs,
i.e., involved with sampling
Furthermore, the interface does not allow an application to read
registers that it has not
previously marked as used, i.e., pfm_read_pmds fails. This mechanism prevents
reading random PMD registers, possibly inherited from other threads.
But here is the interesting case:
- for a simple PMD/PMC pair, the application writes the PMD but not the PMC
It is important to note that on X86, the default context switch code restores
all PMC registers. However, all processors but Pentium 4 have an
optimized version
which only restores the used PMCS.
In the situation outlined above, it means the PMC is not restored,
thus the thread will
pick up the PMC value from a previous thread.
Is that a problem?
At first, it would look like it is. But let's dig deeper.
If that PMC is used to enable/disable a counter or feature, then it is
guaranteed to be zero, i.e.,
it was cleared during context switch out of the thread where it was
used. If the PMC is not an
'enable PMC', then can it be harmful? on X86, at least, it is always
the case that each feature
provides for some enable bit somewhere. So sure, we can pick up a
stale PMC, but it
cannot influence the next PMU user.
Although it may seems fine for now, I think we need a more generic and
robust mechanism
to avoid troubles later. If we elaborate on the example above and
assume we have a PMU
with two PMCs to control a PMD, and only one of the PMC has the enable
bit then we can
run into the issue. This is the case on Pentium 4 and that's why we
save and restore everything.
I think the better solution would be to provide for each PMD a bitmask
of depending PMCs.
When the PMD is written to, then the bitmask of used PMCs for the
event set is updated with
the depending PMCs. This could be done in the generic code.
Do we need this for the other direction (PMC -> PMD)?
Not necessarily, because an application cannot read a PMD it has not
written. Worse
case, there may be spurious interrupts. But there could be issues on
architectures where
it is possible to read PMD registers directly at the user level, e.g.,
X86, IA64. Note that
such mechanism, when present, is only enabled for self-montoring
threads. The kernel
could detect this and systematically restore the entire PMU state.
Any opinions?
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
