From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9664 invoked by alias); 10 Jan 2014 22:37:48 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 9626 invoked by uid 48); 10 Jan 2014 22:37:44 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/12683] Race conditions in pthread cancellation Date: Fri, 10 Jan 2014 22:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.19 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00174.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=12683 --- Comment #12 from Rich Felker --- Your proposed solution is a lot more complex and invasive than mine; it's actually almost equivalent to the first-generation solution I used in musl for the problem, which turned out to be a bad idea, and thus got scrapped. Most importantly, aside from being complex and ugly, it does not actually solve the worst problem, because this case is wrong: "Cancellation delivered between syscall and clearing IN_SYSCALL: The SIGCANCEL handler will immediately cancel the thread." In this case, unless the syscall failed with EINTR, you must not act on the cancellation request. Doing so is non-conforming to the requirement that the side effects upon cancellation match the side effects on EINTR (which is just a fancy way of saying, approximately, that cancellation can only take place if the syscall has already done its job, e.g. closing a fd, transferring some bytes, etc.). In addition, I suspect your solution has further flaws like what happens when you longjmp out of a signal handler that interrupted an AS-safe syscall which is a cancellation point. These issues can be solved with more complexity (extra work in longjmp), but the solution I've proposed is much simpler and has no corner cases that are difficult to handle. -- You are receiving this mail because: You are on the CC list for the bug.