This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/12683] Race conditions in pthread cancellation


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]