From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/292 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Audit help needed: cancellation Date: Mon, 18 Apr 2011 21:46:50 -0400 Message-ID: <20110419014650.GF277@brightrain.aerifal.cx> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1312595708 11479 80.91.229.12 (6 Aug 2011 01:55:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 01:55:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: envelope-from@hidden Tue Apr 19 05:52:01 2011 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:292 Archived-At: As of now, pthread cancellation in musl should behave correctly. Semantics on cancellation should be correct, all functions which are defined as cancellation points should behave as such, and all functions which are specified not to be cancellation points should not cause cancellation. POSIX leaves it to the implementation to decide whether a number of functions should be cancellable or not; in this case, I have generally opted not to make them cancellable unless they can safely be made cancellable without installing cancellation cleanup handlers. Now, the main audit task deals with functions which are not cancellation points, or which are not required to be. I'd like help determining, either by testing or by source audit, that these functions don't call functions which are cancellation points, or if they do, that they use pthread_setcancelstate correctly to block cancellation so that they cannot leak resources or leave inconsistent internal state. POSIX has a list of functions here which MAY be cancellation points: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_05_02 This list is essentially the functions which "need to use" cancellable syscalls in their implementations, so it's a very helpful guide to finding the functions that might have problems. Note that stdio does not need to be tested. musl's stdio uses syscalls directly, since it cannot refer to POSIX symbol names anyway. The same should apply to any functions defined in the C standard, but it wouldn't hurt to verify that they're not wrongly using POSIX symbols. Rich