Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752400AbcCKLj0 (ORCPT ); Fri, 11 Mar 2016 06:39:26 -0500 Received: from port70.net ([81.7.13.123]:35342 "EHLO port70.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbcCKLjS (ORCPT ); Fri, 11 Mar 2016 06:39:18 -0500 Date: Fri, 11 Mar 2016 12:39:15 +0100 From: Szabolcs Nagy To: Ingo Molnar Cc: Rich Felker , Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra Subject: Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Message-ID: <20160311113914.GD29662@port70.net> Mail-Followup-To: Ingo Molnar , Rich Felker , Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra References: <06079088639eddd756e2092b735ce4a682081308.1457486598.git.luto@kernel.org> <20160309085631.GA3247@gmail.com> <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> <20160311093347.GA17749@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160311093347.GA17749@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2728 Lines: 70 * Ingo Molnar [2016-03-11 10:33:47 +0100]: > * Rich Felker wrote: > > > 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 > > As I (tried to!) describe it when describing the cancellation signal, if a > cancellation signal is in flight, it must be waited for in the unlikely event of > cancellation being disabled in the small window where the signal is sent. > > So in your above example, it would do: > > > 1. A has cancellation enabled > > 2. B calls pthread_cancel(A) and sets sticky pending signal blocking signals here is ok. > > 3. A disables cancellation blocking signals here is not ok. (libc changes cancelstate at many places, there should be no syscall in that path.) > 3b. Notices that cancellation request is pending and waits for it > and clears the sticky signal. setcancelstate can be reentered between 'noticing' and 'waiting' if interrupted by a signal. the state change from expect-pending-signal to no-pending-signal cannot be atomic wrt sigwaitinfo unless signals are blocked. what i didnt think about yesterday is that it is ok and possible to only block signals if there was a cancel. (it is not trivial since all the cancel related state changes have to be atomic and there are at least canceled, signaled, cancelstate and canceltype, which have to fit into 32bits and managed together.) > 4. A calls cancellation point and syscall correctly executes > 5. Once A enables cancellation again, the cancellation propagates. > > So I still see no problem. > i think the sticky signal design would work, but more complex than what we have and adds some atomic rmw ops into common code paths and not backward compatible. not using vsyscalls for cancellation-points sounds easier. > > This can be solved with more synchronization in pthread_cancel and > > pthread_setcancelstate, but it seems costly. [...] > > An active signal round trip in itself is very costly (thousands of cycles), a > thread exit is tens of thousands of cycles, and this is a 'slow path' anyway, and > the window is small in any case. > > It's just a correctness synchronization to make sure no sticky signal is pending, > not a real performance concern in practice. > > Thanks, > > Ingo