Date: Tue, 18 Sep 2018 10:56:06 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231445] [patch] sleepq_catch_signals will still enter sleep after a ptrace attach event Message-ID: <bug-231445-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231445 Bug ID: 231445 Summary: [patch] sleepq_catch_signals will still enter sleep after a ptrace attach event Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: valmarelox@gmail.com Created attachment 197188 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D197188&action= =3Dedit patch If a ptrace attach SIGSTOP is queued to a process while that process is on a sleep queue but has not yet entered sleep, the signal will not abort the sl= eep. This behavior which contradicts the expected behavior that happens when the process is interrupted mid sleep - it aborts the sleep and will continue fr= om a user mode boundary when continued. In the current condition after the process is restarted, it will immediately enter the sleep as if no signal was received (this is due to issignal delet= ing signals handled by ptracestop and returning 0, where sleepq_catch_signals u= ses the return value in the pending signals check prior to entering sleep). A proposed patch is attached. I reproduced this issue on a FreeBSD12-CURRENT amd64 machine running on QEMU with multiple cores. --=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-231445-227>