public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/12683] New: Race conditions in pthread cancellation Date: Mon, 18 Apr 2011 22:28:00 -0000 [thread overview] Message-ID: <bug-12683-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=12683 Summary: Race conditions in pthread cancellation Product: glibc Version: unspecified Status: NEW Severity: critical Priority: P2 Component: nptl AssignedTo: drepper.fsp@gmail.com ReportedBy: bugdal@aerifal.cx Created attachment 5676 --> http://sourceware.org/bugzilla/attachment.cgi?id=5676 Demonstration of file descriptor leak due to problem 1 The current approach to implementing pthread cancellation points is to enable asynchronous cancellation prior to making the syscall, and restore the previous cancellation type once the syscall returns. I've asked around and heard conflicting answers as to whether this violates the requirements in POSIX (I believe it does), but either way, from a quality of implementation standpoint this approach is very undesirable due to at least 2 problems, the latter of which is very serious: 1. Cancellation can act after the syscall has returned from kernelspace, but before userspace saves the return value. This results in a resource leak if the syscall allocated a resource, and there is no way to patch over it with cancellation handlers. Even if the syscall did not allocate a resource, it may have had an effect (like consuming data from a socket/pipe/terminal buffer) which the application will never see. 2. If a signal is handled while the thread is blocked at a cancellable syscall, the entire signal handler runs with asynchronous cancellation enabled. This could be extremely dangerous, since the signal handler may call functions which are async-signal-safe but not async-cancel-safe. Even worse, the signal handler may call functions which are not even async-signal-safe (like stdio) if it knows the interrupted code could only be using async-signal-safe functions, and having a thread asynchronously terminated while modifying such functions' internal data structures could lead to serious program malfunction. I am attaching simple programs which demonstrate both issues. The solution to problem 2 is making the thread's current execution context (e.g. stack pointer) at syscall time part of the cancellability state, so that cancellation requests received while the cancellation point is interrupted by a signal handler can identify that the thread is not presently in the cancellable context. The solution to problem 1 is making successful return from kernelspace and exiting the cancellable state an atomic operation. While at first this seems impossible without kernel support, I have a working implementation in musl (http://www.etalabs.net/musl) which solves both problems. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2011-04-18 22:28 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-18 22:28 bugdal at aerifal dot cx [this message] 2011-04-18 22:35 ` [Bug nptl/12683] " bugdal at aerifal dot cx 2011-09-21 18:30 ` bugdal at aerifal dot cx 2012-04-29 2:56 ` bugdal at aerifal dot cx 2012-04-29 2:57 ` bugdal at aerifal dot cx 2012-09-22 23:13 ` bugdal at aerifal dot cx 2013-08-16 15:32 ` carlos at redhat dot com 2013-08-16 15:34 ` carlos at redhat dot com 2013-08-16 15:34 ` carlos at redhat dot com 2013-08-16 16:22 ` bugdal at aerifal dot cx 2013-08-16 16:59 ` carlos at redhat dot com 2013-08-16 17:14 ` bugdal at aerifal dot cx 2013-08-16 18:09 ` carlos at redhat dot com 2014-01-10 20:25 ` carlos at redhat dot com 2014-01-10 21:31 ` carlos at redhat dot com 2014-01-10 22:37 ` bugdal at aerifal dot cx 2014-01-12 18:31 ` carlos at redhat dot com 2014-01-12 23:55 ` bugdal at aerifal dot cx 2014-01-13 1:52 ` carlos at redhat dot com 2014-01-13 4:37 ` bugdal at aerifal dot cx 2014-01-14 14:51 ` carlos at redhat dot com 2014-02-16 19:42 ` jackie.rosen at hushmail dot com 2014-05-28 19:47 ` schwab at sourceware dot org 2014-05-28 19:47 ` schwab at sourceware dot org 2014-06-27 13:35 ` fweimer at redhat dot com 2014-07-19 18:44 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-19 18:54 ` bugdal at aerifal dot cx 2014-07-20 18:15 ` sstewartgallus00 at mylangara dot bc.ca 2014-07-20 18:41 ` bugdal at aerifal dot cx 2014-08-19 14:08 ` azanella at linux dot vnet.ibm.com 2014-08-28 15:02 ` carlos at redhat dot com 2015-01-15 13:20 ` dan at censornet dot com 2015-01-15 13:31 ` bugdal at aerifal dot cx 2015-01-15 14:01 ` dan at censornet dot com 2020-06-08 14:04 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12683-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).