[Bug 207085] pmc assertion failure: pmc %p non-NULL

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Feb 10 17:00:09 UTC 2016


            Bug ID: 207085
           Summary: pmc assertion failure: pmc %p non-NULL
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: joss.upton at yahoo.com
                CC: freebsd-amd64 at FreeBSD.org, joss.upton at yahoo.com
                CC: freebsd-amd64 at FreeBSD.org

I see these panics with INVARIANTS enabled on 10.2-R on an SMP machine running
many processes using hwpmc in parallel.

[core,2376] PHW pmc non-NULL
cpuid = 1

pmc_process_exit() does the following:

and the various drivers do *_release_pmc():
        ... KASSERT(phw->phw_pmc == NULL) ...

What I'm seeing is on an SMP machine, from time to time a process which
owns PMCs races with a process that has attached PMCs.  free_owner_pmcs()
calls *_release_pmc() which checks to make sure the per-cpu counter
isn't in use.  A process with attached pmcs will have freed them with
both the pmc_lock and scheduler lock held.  But, a process being scheduled
onto the pmc can sneak in between the critical_exit() and the sx_unlock(),
but before the free_owner_pmcs() resulting in an assertion failure.

free_owner_pmcs can't be protected by the scheduler lock because it
may need to sleep waiting on sampling counters to come off the cpu.  I'm
not sure how to approach a fix other than disabling the KASSERT, and I'm not
sure if that's safe.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the freebsd-amd64 mailing list