This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/12683] Race conditions in pthread cancellation
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 10 Jan 2014 22:37:44 +0000
- Subject: [Bug nptl/12683] Race conditions in pthread cancellation
- Auto-submitted: auto-generated
- References: <bug-12683-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=12683
--- Comment #12 from Rich Felker <bugdal at aerifal dot cx> ---
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.