From owner-freebsd-bugs@freebsd.org Fri May 12 00:44:16 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6527BD5E66D for ; Fri, 12 May 2017 00:44:16 +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 mx1.freebsd.org (Postfix) with ESMTPS id 4A3B33BA for ; Fri, 12 May 2017 00:44:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4C0iGBW041740 for ; Fri, 12 May 2017 00:44:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219228] EINTR on thread with full signal mask. Date: Fri, 12 May 2017 00:44:16 +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: 10.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: parakleta@darkreality.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 00:44:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219228 Bug ID: 219228 Summary: EINTR on thread with full signal mask. Product: Base System Version: 10.3-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: parakleta@darkreality.org Created attachment 182523 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182523&action= =3Dedit Test program: compile with `cc -lthr main.c`; Send '^t^t^t^c' to observe problem. I don't know if this is a bug or within the bounds of undefined behaviour, = but I certainly found it surprising. Essentially I have a thread with all possible signals masked and I expect t= hat it should never return the error of EINTR because it will never catch any signals. It seems however that if there are signals queued (not just pendi= ng) then when the signals are dequeued then the last started thread is interrup= ted even if it doesn't handle the signal. In the attached sample program if SIGINFO is sent three times, the first is handled (but then the handler blocks at `pause()`), the second is pending, = and the third is queued. When then sending a SIGINT the handler unblocks, retu= rns, then receives the pending SIGINFO and blocks again, but then the worker thr= ead is woken and interrupted with EINTR. The test program prints '*' for every iteration of the worker thread (1 per second), 'HND' when the signal handler is entered, and 'WRK: Interrupted sy= stem call' when the worker thread is interrupted. If SIGINFO is only sent two times then the EINTR in the worker thread never occurs. If it is sent more than three times then an EINTR is received every time a queued signal is moved from the queue to pending. I don't understand this area of the kernel code enough to know where the problem is, but I don't believe a masked signal should cause an EINTR. If = it is necessary to interrupt a thread for some reason when the signal is masked everywhere is there any chance that this could be forced to the main thread rather than to the last started. At least the main thread is identifiable.= =20 With the current behaviour I cannot even have a single sacrificial thread to handle these because whenever a new thread is started it becomes the target= of the EINTR. --=20 You are receiving this mail because: You are the assignee for the bug.=