From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9582 Path: news.gmane.org!not-for-mail From: Linus Torvalds 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 11:27:43 -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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1457724482 12250 80.91.229.3 (11 Mar 2016 19:28:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 19:28:02 +0000 (UTC) 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 Original-X-From: musl-return-9595-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 11 20:28:00 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 1aeSj8-0005eA-Rp for gllmg-musl@m.gmane.org; Fri, 11 Mar 2016 20:27:58 +0100 Original-Received: (qmail 21935 invoked by uid 550); 11 Mar 2016 19:27:56 -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 21914 invoked from network); 11 Mar 2016 19:27:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=X9vqImfmCCp0bvUI0hWLwOlfke+0lTqERcWANiMs4C8=; b=BMh/u+XgZLhv7sEW3pQGJGFnuV2o+v6q7VVEEvu09Oj45FHSZjSv8m6a/O3bQ53xL+ D+AYXDOaMWV51xRxDoTc31Ji4sRRiH1YQ2E9zrrKl71ljjqdw7gO0/MauaivFiQJPpP8 f3pmZryYXNxIkXSkJyjHoGpnisQE8MqAF1xTZNLrlElN9Xyh124NsFrq8VALCLisLTqk fBO+822+n9u7l7YR/tGMy1Rt7lq1h2KiQE0I2hvxbk6Se8JEJgR3rtnDAU3BIVAHVXJU Pl+kd6Lre7hc4Ve0LejXh+rzLCsSm+NRUAOeMK9TuT+aH5vxJ3PXbuysAwSXC7WmH+Mi pCIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=X9vqImfmCCp0bvUI0hWLwOlfke+0lTqERcWANiMs4C8=; b=K6K9XpgnHahDCim6506jEurapgibdpCqgjLd1/j9Wy9CG0/R90sy/AnVWe7jYT0qgz SA0+lnJpn9JsIPEb7pmXat/M3lv+Nhj4Yb+/ZTGk3kUxlv6QmK+AaPUmZf74Pxz2wEwX Ot4AFRtlXwfeqkwtmrJ2c/wdpYxc1qi3P1WMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=X9vqImfmCCp0bvUI0hWLwOlfke+0lTqERcWANiMs4C8=; b=YvFj8rbO2ljBP94eCE7dgGLIE3m2d4rNq2UvTz1zsR6QcDuMwdgMna/oyhIhknv6ND 7DCWz4BTbrajygUAAyNBcTqAfIWGQHaL6BD+WEXlutZZIgt7R64d8MiUnUMkcMZGwmQh K2Qi+ChWS4R0i8Z/bGQJWT8XzZPmIXYloNneNYf3RgyyPqLpeBqaMI7MwUFDya/Hfo6X DYbuQDcYpY0CDIcgZfT+KshlDVpR73FWy/KaUzqd3wYrGwQQEmBFCGQxfOtZgER49s3f yeswCy3HSMbPPnrjcHw2fN1Tx5y7ngsjCVPxrbRWPchliVt4gI49FKL/E0Ebhv32I9G8 f9Bg== X-Gm-Message-State: AD7BkJJt2JO23lOvMH75Rx5DbrgYEF6UgJamxM92GUs+wrkFs/Yy9J06DQx3dGx8Z4Q1QF+q3XX0tO7qM3ji5g== X-Received: by 10.50.112.10 with SMTP id im10mr5801640igb.93.1457724463578; Fri, 11 Mar 2016 11:27:43 -0800 (PST) Original-Sender: linus971@gmail.com In-Reply-To: <20160311113914.GD29662@port70.net> X-Google-Sender-Auth: A4EgAf5ZfFZ0m4RNFhwouVdEUnE Xref: news.gmane.org gmane.linux.lib.musl.general:9582 gmane.linux.kernel:2175172 Archived-At: 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. Linus