Michael Ellerman <m...@ellerman.id.au> writes: > Hi Pedro, > > Thanks for looking into this, how did you detect this? Do you have a > test case?
Hello, I'm working on allowing these registers to be accessed through GDB, which is where I saw this happen. Then I used a small program that traces another, then reads and tries to write to the regset, but not in linux selftest format. > I don't think Anshuman wrote it this way on purpose, but added him to Cc > in case he remembers. > > But I don't think this fix is necessarily right. If we are setting the > EBB regs via ptrace then it doesn't matter if they were previously in > use or not, we should just set them. What *does* matter is that at the > end of the function we set used_ebb to true, because otherwise the > values we have set will not actually be used when the process is > rescheduled. Now I'm not sure why the ptrace calls for the ebb regset are guarded with used_ebb in the first place. The save/restore_sprs functions in kernel/process.c seem to handle the ebb registers regardless of this flag, and it seems to be possible for user programs to read and write to these registers even without having first created a perf event. The flag only appears to be used in perf/core_book3s.c in the ebb_event_add function, and the pmu registers (mmcr0, etc) only seem to be saved to and restored from the thread_struct through ebb_switch_in/out. So maybe the original intent was to guard the pmu_get/set functions with used_ebb instead? I'm not sure about this, because I don't know if it possible for a ptrace call to happen between ebb_event_add and the first ebb_switch_in for a thread. Thanks! -- Pedro
