From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751111AbcCKJeB (ORCPT <rfc822;w@1wt.eu>);
	Fri, 11 Mar 2016 04:34:01 -0500
Received: from mail-wm0-f67.google.com ([74.125.82.67]:36029 "EHLO
	mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750742AbcCKJdw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 11 Mar 2016 04:33:52 -0500
Date: Fri, 11 Mar 2016 10:33:47 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Rich Felker <dalias@libc.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        "musl@lists.openwall.com" <musl@lists.openwall.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation
 helpers
Message-ID: <20160311093347.GA17749@gmail.com>
References: <06079088639eddd756e2092b735ce4a682081308.1457486598.git.luto@kernel.org>
 <20160309085631.GA3247@gmail.com>
 <20160309113449.GZ29662@port70.net>
 <CA+55aFzOcxbhXCm01+NMgY9=THYgjojvDGeYsnxe-vWfiX4X0g@mail.gmail.com>
 <20160310033446.GL9349@brightrain.aerifal.cx>
 <20160310111646.GA13102@gmail.com>
 <20160310164104.GM9349@brightrain.aerifal.cx>
 <20160310180331.GB15940@gmail.com>
 <20160310232819.GR9349@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160310232819.GR9349@brightrain.aerifal.cx>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Rich Felker <dalias@libc.org> 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
> 3. A disables cancellation
  3b. Notices that cancellation request is pending and waits for it
      and clears the sticky signal.
  4. A calls cancellation point and syscall correctly executes
  5. Once A enables cancellation again, the cancellation propagates.

So I still see no problem.

> 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