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

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207085

            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:
        sx_xlock();
        critical_enter();
        free_attached_pmcs...
        critical_exit();
        free_owner_pmcs...
        sx_unlock();

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 the assignee for the bug.