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 17630 invoked from network); 17 Jul 2020 23:31:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 23:31:21 -0000 Received: (qmail 12085 invoked by uid 550); 17 Jul 2020 23:31:11 -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 12067 invoked from network); 17 Jul 2020 23:31:10 -0000 Date: Fri, 17 Jul 2020 19:30:58 -0400 From: Rich Felker To: Hydro Flask Cc: musl@lists.openwall.com, Carlos O'Donell , Florian Weimer Message-ID: <20200717233058.GJ14669@brightrain.aerifal.cx> References: <04c05d65470b5c94808481eaf724cc5d@yqxmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449cc77dc2bc153de7a2633ee8613b42@yqxmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Idea: futex() system call entry point On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote: > On 2020-07-17 14:19, Rich Felker wrote: > >On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote: > >>* Hydro Flask [2020-07-17 11:57:36 -0700]: > >>> In general the user should ensure that cancellation is disabled one way or > >>> another when the call is called from the signal handler, or that the call is > >>> being done in a AC-safe region. There are a variety of ways to do this as > >>> discussed in POSIX. > >> > >>it's possible to do this, but it's a rare requirement. > >> > >>futex is not a nice syscall to expose in c. > >> > >>currently there is disagreement about how to expose it: > >>directly the linux api (which is variadic and not very > >>typesafe) or separate calls for the useful operations > >>(futex_wait, futex_wake, etc but the exact c api is > >>less clear then). > >> > >>because of new time_t abi on 32bit targets, the timeout > >>argument to futex is another reason to expose it in c > >>instead of allowing users to use it via syscall (if they > >>use the libc timespec type with the raw syscall that can > >>be broken). > >> > >>in any case it's better to discuss this on libc-alpha > >>since musl and glibc must expose the same api for it > >>to be useful and it is harder to get this into glibc. > > > >CC'ing libc-coord would also be appropriate for this, I think, even if > >it is Linux-only and not relevant to the BSD etc folks there. > > > >I do want to expose futex function but I don't want to end up with > >something gratuitously incompatible/conflicting with what glibc ends > >up doing. > > I didn't realize this discussion was more complex. Non-Linux/Glibc > is not my use case so I would have proposed "musl_futex()" to make > things move quicker but not if adding non-standard calls is > something Linux libcs avoid without consensus. > > 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? This does not resolve the lack of a proper futex() function, but it does seem preferable to the hacks proposed above. Rich