mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Audit help needed: cancellation
Date: Mon, 18 Apr 2011 21:46:50 -0400	[thread overview]
Message-ID: <20110419014650.GF277@brightrain.aerifal.cx> (raw)

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


                 reply	other threads:[~2011-04-19  1:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20110419014650.GF277@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).