Date: Wed, 10 Feb 2016 17:00:09 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207085] pmc assertion failure: pmc %p non-NULL Message-ID: <bug-207085-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207085 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.upton@yahoo.com CC: freebsd-amd64@FreeBSD.org, joss.upton@yahoo.com CC: freebsd-amd64@FreeBSD.org I see these panics with INVARIANTS enabled on 10.2-R on an SMP machine runn= ing many processes using hwpmc in parallel. [core,2376] PHW pmc non-NULL cpuid =3D 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 =3D=3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207085-8>