Date: Wed, 28 Mar 2018 17:16:12 +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@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227041 Bug ID: 227041 Summary: Kernel cannot fork new process after calling pmc_deatch with pid 0 Product: Base System Version: 11.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: dom@itsallbroken.com When the kernel has the hwpmc module loaded (and likely when compiled with hwpmc support too) calling pmc_detach with a pid of 0 (or NULL) followed by calli= ng pmc_release prevents the OS from forking any new processes for any user afterwards - existing processes seem to continue to run, but the system won= 't even exec "reboot". Nothing is printed to the console or logs. The manpage for pmc_attach(3) states that: Function pmc_detach() is used to detach a process scope PMC specified by argument pmcid from a process specified by argument pid. Argument pid may be zero to denote the current process. This behaviour seems to be fine for pmc_attach, but not for pmc_detach. If security.bsd.unprivileged_proc_debug is non-zero (the default?) this can= be triggered from a userland process. Tested on FreeBSD 11.1-RELEASE-p8 running on amd64 with hwpmc loaded at run= time but probably applies to other versions and architectures. Reproducer at https://github.com/domodwyer/pmc-crash/blob/master/pmc-crash.c --=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>