Page MenuHomeFreeBSD

hwpmc: consistently validate PMC class in allocation method
ClosedPublic

Authored by mhorne on Aug 2 2021, 9:03 PM.

Details

Summary

It is always a good idea. In one case, attempting to allocate N+1 PMCs
from a class with N hardware counters would incorrectly attempt to
allocate from the next class in the list. Without this validation, this
can lead to all kinds of unexpected behaviour.

Since powerpc_allocate_pmc() is used by both the mpc7xxx and ppc970
classes, add a new global to track which is active (it will never be
both).

Test Plan

On my desktop with 8 programmable counters, calling pmcstat with 9 separate events will panic the system. With this patch, it will fail to allocate the 9th, as expected.

See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253687#c16

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

mhorne requested review of this revision.Aug 2 2021, 9:03 PM
mhorne edited the test plan for this revision. (Show Details)
This revision is now accepted and ready to land.Aug 17 2021, 11:21 AM

Worked fine on POWER9.
For PowerPC, without these changes the allocation of more programmable counters than available already failed, because of the check for the counter number in allocate. But, as you said, it is always a good idea to validate the PMC class too.

Worked fine on POWER9.
For PowerPC, without these changes the allocation of more programmable counters than available already failed, because of the check for the counter number in allocate. But, as you said, it is always a good idea to validate the PMC class too.

That's right, the issue described only affects platforms which register more than one hwpmc class (where pcd->pcd_num != md->pmd_npmc).