From owner-freebsd-bugs@freebsd.org Tue Sep 18 10:56:08 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46806109A97B for ; Tue, 18 Sep 2018 10:56:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CC03A8AE90 for ; Tue, 18 Sep 2018 10:56:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 905B7109A97A; Tue, 18 Sep 2018 10:56:07 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F04D109A979 for ; Tue, 18 Sep 2018 10:56:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E2DD8AE8F for ; Tue, 18 Sep 2018 10:56:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5A3DC1B279 for ; Tue, 18 Sep 2018 10:56:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w8IAu6VX046060 for ; Tue, 18 Sep 2018 10:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8IAu6SC046059 for bugs@FreeBSD.org; Tue, 18 Sep 2018 10:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Tue, 18 Sep 2018 10:56:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: valmarelox@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 10:56:08 -0000 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.=