From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9568 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Date: Fri, 11 Mar 2016 02:49:59 +0100 Message-ID: <20160311014959.GC29662@port70.net> References: <20160309113449.GZ29662@port70.net> <20160310033446.GL9349@brightrain.aerifal.cx> <20160310111646.GA13102@gmail.com> <20160310164104.GM9349@brightrain.aerifal.cx> <20160310180331.GB15940@gmail.com> <20160310232819.GR9349@brightrain.aerifal.cx> <20160311001853.GA10198@port70.net> <20160311004858.GS9349@brightrain.aerifal.cx> <20160311013946.GB29662@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457661021 30358 80.91.229.3 (11 Mar 2016 01:50:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 01:50:21 +0000 (UTC) To: Rich Felker , Ingo Molnar , Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra Original-X-From: musl-return-9581-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 11 02:50:14 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aeCDV-00052r-An for gllmg-musl@m.gmane.org; Fri, 11 Mar 2016 02:50:13 +0100 Original-Received: (qmail 19516 invoked by uid 550); 11 Mar 2016 01:50: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: Original-Received: (qmail 19494 invoked from network); 11 Mar 2016 01:50:11 -0000 Mail-Followup-To: Rich Felker , Ingo Molnar , Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra Content-Disposition: inline In-Reply-To: <20160311013946.GB29662@port70.net> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9568 gmane.linux.kernel:2174521 Archived-At: * Szabolcs Nagy [2016-03-11 02:39:47 +0100]: > * Rich Felker [2016-03-10 19:48:59 -0500]: > > On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote: > > > * Rich Felker [2016-03-10 18:28:20 -0500]: > > > > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote: > > > > > > > > > > The sticky signal is only ever sent when the thread is in cancellable state - and > > > > > if the target thread notices the cancellation request before the signal arrives, > ^^^^^^... > > > > > it first waits for its arrival before executing any new system calls (as part of > ^^^^^^... > > > > > the teardown, etc.). > > > > > > > > > > So the C library never has to do complex work with a sticky signal pending. > > > > > > > > > > Does that make more sense to you? > > > > > > > > No, it doesn't work. Cancellability of the target thread at the time > > > > of the cancellation request (when you would decide whether or not to > > > > send the signal) has no relation to cancellability at the time of > > > > calling the cancellation point. Consider 2 threads A and B and the > > > > following sequence of events: > > > > > > > > 1. A has cancellation enabled > > > > 2. B calls pthread_cancel(A) and sets sticky pending signal > > > > 3. A disables cancellation > > > > 4. A calls cancellation point and syscall wrongly gets interrupted > > > > > > > > This can be solved with more synchronization in pthread_cancel and > > > > pthread_setcancelstate, but it seems costly. pthread_setcancelstate > > > > would have to clear pending sticky cancellation signals, and any > > > > internal non-cancellable syscalls would have to be made using the same > > > > mechanism (effectively calling pthread_setcancelstate). A naive > > > > implementation of such clearing would involve a syscall itself, > > > > > > i think a syscall in setcancelstate in case of pending sticky signal > > > is not that bad given that cancellation is very rarely used. > > > > I agree, but it's not clear to me whether you could eliminate syscalls > > in the case where it's not pending, since AS-safe lock machinery is > > hard to get right. I don't see a way it can be done with just atomics > > because the syscall that sends the signal cannot be atomic with the > > memory operating setting a flag, which suggests a lock is needed, and > > then there are all sorts of issues to deal with. > > > > i think this is not a problem and the above marked text hints for > a solution: just call pause() to wait for the sticky signal if > self->cancelstate indicates that there is one comming or pending. > > t->cancelstate always have to be atomically modified but sending > the sticky signal can be delayed (does not have to be atomic with > the memory op). > i take this back, if there are signals between the check of self->cancelstate and pause() in setcancelstate that can cause problems (the sticky signal will not hit pause but something else).