Date: Tue, 05 Aug 2014 23:05:41 +0200 From: Jens Gustedt <jens.gustedt@...ia.fr> To: musl@...ts.openwall.com Subject: Re: PATCH: don't call cleanup handlers after a regular return from the thread start function Hello, Am Dienstag, den 05.08.2014, 15:41 -0400 schrieb Rich Felker: > On Tue, Aug 05, 2014 at 09:06:16PM +0200, Jens Gustedt wrote: > > But I have another reason for wanting that, future compatibility with > > C threads. Programs that are written for C threads will not be aware > > of such interdictions. Concretely in our case of my C thread v3 patch > > a user can longjmp from a once-init-handler (written by her or him) > > through pthread_once (in libc, for musl with pthread_cleanup_push) to > > the thread start function (again user code) and then return from > > there. (All of this seems to be allowed by POSIX) > > Such a longjmp is UB unless it's explicitly permitted by the standard > -- same as longjmp out of qsort. Which standard are you refering to? I don't find any mention of such a thing in the C standard. In the contrary, I find a lot of contexts where longjmp is explicitly forbidden, such as at_exit and similar. bsearch, qsort and call_once are not among these, and there is no general mention of longjmp and "callback" contexts. (I just find your second message. I don't find the "shall return" for the comparison function as binding to exclude longjmp, for bsearch this might even be tempting. For call_once, I agree, it is probably lack of consideration.) > There's no guarantee to a function > called as a callback from the standard library that the calling > function does not have internal state which would be left in an > inconsistent state by longjmp'ing out. Don't get me wrong, it isn't a brilliant idea to do longjmp from such callbacks, but I don't see that you have an argument here. The definition of setjmp/longjmp clearly states which circumstance make it UB to use them. For the rest, this *defines* the behavior for all other contexts, including callbacks, unless explicitly forbidden. > If call_once is explicitly required to support longjmp, It is not explicitly forbidden and I think this is sufficient to allow for it. I don't know about the equivalent for the pthread tools, though. > then a separate implementation of call_once is needed for C11 yes > without cancellation support. no, it needs cancellation support that doesn't use local objects, see below. > However I doubt this usage is supported, since > the state of the once_flag would have to be specified for such > interrupted calls, and I see no such specification. > > > I consider to not execute the cleanup handlers a little bit more > > friendly than executing them. > > musl does not do either. It's simply UB. At the point where you're > claiming the cleanup handler is executed, the pointer being > dereferenced is to an object whose lifetime has ended, so it's not > even making a call to the cleanup handler but simply invoking UB. Aren't you playing a bit with words, here? Fact is, that the handler might be called in real life. We are not obliged to be nasty when (and if!) the user is invoking UB. For the case of pthread_once or call_once, we could get away with it by having the `struct __ptcb` static at that place. The caller of the callback holds a lock at the point of call, so there would be no race on such a static object. I will prepare a patch for call_once to do so, just to be on the safe side. This would incur 0 cost. The same could be used for pthread_once. > > Another possibility would be to split the behavior > > > > - abort for pthreads (this is nicer than executing the handlers or > > than silently ignore them) > > > > - ignore for C threads > > There's no way it can happen for C threads unless they're actually > using pthread_cleanup_push, and the relevenat code that might be > returning is aware of POSIX and the reules for use of > pthread_cleanup_push. I don't think it is as simple as that. From C you might use a third party library that on a specific platform uses pthread features under the hood. E.g gcc's libatomic is such a candidate, they are using pthread_mutex_t without telling you. OpenMP also comes in mind. And who knows want the future will bring on such mixed platforms. Jens -- :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.