From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9583 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.kernel,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Date: Fri, 11 Mar 2016 11:30:32 -0800 Message-ID: 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> <20160311113914.GD29662@port70.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1457724668 15239 80.91.229.3 (11 Mar 2016 19:31:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 19:31:08 +0000 (UTC) Cc: Ingo Molnar , Rich Felker , Andy Lutomirski , "the arch/x86 maintainers" , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra To: Linus Torvalds Original-X-From: linux-kernel-owner@vger.kernel.org Fri Mar 11 20:31:01 2016 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aeSm3-0007qs-MG for glk-linux-kernel-3@plane.gmane.org; Fri, 11 Mar 2016 20:31:00 +0100 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932261AbcCKTaz (ORCPT ); Fri, 11 Mar 2016 14:30:55 -0500 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:34046 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932070AbcCKTax (ORCPT ); Fri, 11 Mar 2016 14:30:53 -0500 Original-Received: by mail-ob0-f169.google.com with SMTP id ts10so123175218obc.1 for ; Fri, 11 Mar 2016 11:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3lFcHwTqBd4CRdqn8ZgddMPcyu1sHv5eaMph6jNxXuo=; b=01o+L09zr72hSF2fxWKkid9klGYpPojFfHS/4XjIcv+YtQOxtPLs7nEeWUtcMIhsrp 6NEFTGdLc4kVdpWnPOcBAIP1AcZp1YMdZixrvuu5dLuMnC/Tj6OWi+E1bURtxmtublVL KLeygF00w9i3bIshkcOxjX0qIv5ShYdeeXySq+8m4VINyNw8UbJsleA10dksBfTExKpc iTq4n709sDCmN6L1YD0TgcI1+Lemji6fCzhet0HTtcWu/4E7fvRpIX27bawLCJrXMYiu VhuII67SuRmLjz03RRa5saKmRqTQWz15B6hMWVbIPEb4+WEAh9RARriqVayde8sMsaeY 9j5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3lFcHwTqBd4CRdqn8ZgddMPcyu1sHv5eaMph6jNxXuo=; b=YYg5SCyaamOaZutB9eomEDpxH/oJoT4jvh4u9+Gh5U1BlS9K2Y+eIF3ICdWT3FGuz9 xONf902HNx+kCexSp7AerwTVmfQaTJnz33RUUO/NhwMAXzHA26E0YssyQKosUqti4tNL 3xA+pl5lH8SzrwWlLlYvA5HFUISF4oILnAY1zL47JhaMyxZUt8R7VmWJQqa84OWoiig6 cUn3+isoTrD5Y57NVvE/egK8T2mo2L2XP+huCjJtg6ffrcfCYrnWqb48gze8NrheIrmQ u+s38FEU6/j1Ay6pOFsFEpvePhxaYNUCOF15Age1Hk3TFlAtsV/E9QbJYjug1xUe36Gv 7qDg== X-Gm-Message-State: AD7BkJIBsrfgAuheOtPADU3oOjHSnLRj6G82YcAceRA1wXij+UMy7sMcmaa6c2qYdJdCreOSzyIElYJgKDmob0nG X-Received: by 10.60.82.10 with SMTP id e10mr7229518oey.0.1457724652462; Fri, 11 Mar 2016 11:30:52 -0800 (PST) Original-Received: by 10.202.202.201 with HTTP; Fri, 11 Mar 2016 11:30:32 -0800 (PST) In-Reply-To: Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:2175175 gmane.linux.lib.musl.general:9583 Archived-At: On Fri, Mar 11, 2016 at 11:27 AM, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 3:39 AM, Szabolcs Nagy wrote: >> >> 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. > > Hmm. Ok, so I think I understand your needs, and your current model > does sound easier. But the cost of not using vsyscalls is really quite > high. > > It sounds like the main worry is that some system calls are guaranteed > cancellation points, and if the signal slips in between your > cancellation point check and the system call, you lose that ability. > > I'm assuming that if the "canceltype" is asynchronous, you never have > this problem, because the cancellation can be done in the signal > handler itself, which avoids the whole race. > > Am I getting closer to understanding the particular semantics you are > looking for? > > Because if that's the case, I wonder if what you really want is not > "sticky signals" as much as "synchronous signals" - ie the ability to > say that a signal shouldn't ever interrupt in random places, but only > at well-defined points (where a system call would be one such point - > are there others?) > > So then you could make "pthread_setcanceltype()" just set that flag > for the cancellation signal, and just know that the signal itself will > always be deferred to such a synchronous point (ie system call entry). > > We already have the ability to catch things at system call entry > (ptrace needs it, for example), so we could possibly make our signal > delivery have a mode where a signal does *not* cause user space > execution to be interrupted by a signal handler, but instead just sets > a bit in the thread info state that then causes the next system call > to take the signal. I think that this would almost work for musl, except that musl would still need to be able to tell whether the syscall that eventually gets interrupted is a cancellation point, which still may require some ability to unwind from the vdso. The syscall handler can easily tell the syscall number (it's in EAX), but it may need the effective EIP as well. --Andy