From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9082 invoked from network); 18 Jul 2020 07:57:04 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jul 2020 07:57:04 -0000 Received: (qmail 18133 invoked by uid 550); 18 Jul 2020 07:57:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18115 invoked from network); 18 Jul 2020 07:57:00 -0000 Date: Sat, 18 Jul 2020 09:56:48 +0200 From: Szabolcs Nagy To: Hydro Flask Cc: musl@lists.openwall.com, Carlos O'Donell , Florian Weimer Message-ID: <20200718075648.GC3210874@port70.net> Mail-Followup-To: Hydro Flask , musl@lists.openwall.com, Carlos O'Donell , Florian Weimer References: <87pn8uwu18.fsf@oldenburg2.str.redhat.com> <4095a8a7f75becee9bcfc71024e43802@yqxmail.com> <20200717092111.GA3210874@port70.net> <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com> <03e28c2e6beb406c3a1ce3bfa99c67eb@yqxmail.com> <20200717211050.GB3210874@port70.net> <20200717211933.GI14669@brightrain.aerifal.cx> <449cc77dc2bc153de7a2633ee8613b42@yqxmail.com> <20200717233058.GJ14669@brightrain.aerifal.cx> <75e93ed84f40957c3750fb42c366447b@yqxmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75e93ed84f40957c3750fb42c366447b@yqxmail.com> Subject: Re: [musl] Idea: futex() system call entry point * Hydro Flask [2020-07-17 18:21:27 -0700]: > On 2020-07-17 16:30, Rich Felker wrote: > > On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote: > > > Maybe a less complex suggestion is to expose a syscall_cp() > > > function, so you can get cancellation point functionality for any > > > system call. I actually quite like that option. How does that sound? > > > > In the specific case of futex waits, it's not clear to me that there's > > any side effect for which you need to know in the cancellation handler > > whether it occurred, so why can't you just enable async cancel around > > syscall() and disable it again after? > > Oh I hadn't thought of that. That's actually a pretty good short-term > solution. So you're saying: > > int fuxex_wait(int *uaddr, int val, const struct timespec *timeout) > { > int old, ret; > > /* pthread_setcanceltype() automatically calls > pthread_testcancel() if async is enabled */ > ret = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &old); > if (ret) { > errno = ret; > ret = -1; > } > ret = syscall(SYS_futex, uaddr, FUTEX_WAIT, val, timeout); note that passing libc types (timespec) to raw syscall is broken (at least on 32bit targets, but in general a libc type may not match kernel types if this has to be portable to other libcs). you have to locally create a type that is known to match the kernel abi on the targets you care about and translate between the libc type and that. > old = pthread_setcanceltype(old, &old); > if (old) abort(); > return ret; > } > > I think you're right that even if the futex call succeeds, it's fine to > cancel since it does not mutate any meaningful observable state. I think > that should satisfy all my requirements when doing this on musl. > pthread_testcancel/pthread_setcanceltype should be AS-safe in musl if > cancellation is disabled or the interrupted code is AC-safe. > > That should likely also work in other libcs assuming a sane implementation > of all the required functions involved. Thank you > > Hydro