Date: Wed, 28 Mar 2018 23:21:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 227041] Kernel cannot fork new process after calling pmc_deatch with pid 0 Message-ID: <bug-227041-8-hhx9VnQqNf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227041-8@https.bugs.freebsd.org/bugzilla/> References: <bug-227041-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227041 --- Comment #2 from Conrad Meyer <cem@freebsd.org> --- The situation described sounds like a deadlock or livelock. If you reprodu= ce it with an INVARIANTS+WITNESS kernel, do you get a LOR warning? Does the pmc-crash program return/complete? Basic investigation: The userspace libpmc functions pmc_detach/pmc_release() translate pretty directly into the (gigantic) kernel syscall pmc_syscall_handler(), PMC_OP_PMCDETACH and PMC_OP_PMCRELEASE. If 0 is passed as pid, the current thread's pid is substituted. pfind() acquires proc lock after pmc sx xlock. The proc lock is dropped and then t= he process is detached via pmc_detach_process(). Are you sure if pmc_release() is required? It doesn't look like it does anything special with locking. I have not investigated deeply. --=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-227041-8-hhx9VnQqNf>