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@FreeBSD.org Reporter: joss.up...@yahoo.com CC: freebsd-am...@freebsd.org, joss.up...@yahoo.com CC: freebsd-am...@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. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"