[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20110419014650.GF277@brightrain.aerifal.cx>
Date: Mon, 18 Apr 2011 21:46:50 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Audit help needed: cancellation
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
