From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@kernel.org>, Rich Felker <dalias@libc.org>,
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
Date: Fri, 11 Mar 2016 11:27:43 -0800 [thread overview]
Message-ID: <CA+55aFxvMM3j1aWjN-kr5Hn8CUC_RSNw5hc+X8zFXMaMv+mGww@mail.gmail.com> (raw)
In-Reply-To: <20160311113914.GD29662@port70.net>
On Fri, Mar 11, 2016 at 3:39 AM, Szabolcs Nagy <nsz@port70.net> 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
next prev parent reply other threads:[~2016-03-11 19:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 1:24 [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski
2016-03-09 8:56 ` Ingo Molnar
2016-03-09 11:34 ` [musl] " Szabolcs Nagy
2016-03-09 11:40 ` Szabolcs Nagy
2016-03-09 19:47 ` Linus Torvalds
2016-03-09 20:57 ` Andy Lutomirski
2016-03-09 21:26 ` Linus Torvalds
2016-03-10 10:57 ` Ingo Molnar
2016-03-10 3:34 ` Rich Felker
2016-03-10 11:16 ` Ingo Molnar
2016-03-10 16:41 ` Rich Felker
2016-03-10 18:03 ` Ingo Molnar
2016-03-10 23:28 ` Rich Felker
2016-03-11 0:18 ` Szabolcs Nagy
2016-03-11 0:48 ` Rich Felker
2016-03-11 1:14 ` Andy Lutomirski
2016-03-11 1:39 ` Szabolcs Nagy
2016-03-11 1:49 ` Szabolcs Nagy
2016-03-11 1:55 ` Rich Felker
2016-03-11 9:33 ` Ingo Molnar
2016-03-11 11:39 ` Szabolcs Nagy
2016-03-11 19:27 ` Linus Torvalds [this message]
2016-03-11 19:30 ` Andy Lutomirski
2016-03-11 19:39 ` Linus Torvalds
2016-03-11 19:44 ` Linus Torvalds
2016-03-12 17:05 ` Ingo Molnar
2016-03-12 18:10 ` Rich Felker
2016-03-12 17:00 ` Ingo Molnar
2016-03-12 18:05 ` Rich Felker
2016-03-12 18:48 ` Ingo Molnar
2016-03-12 19:08 ` Rich Felker
2016-03-12 17:08 ` Ingo Molnar
2016-03-09 17:58 ` Andy Lutomirski
2016-03-09 21:19 ` Andy Lutomirski
2016-03-12 18:13 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+55aFxvMM3j1aWjN-kr5Hn8CUC_RSNw5hc+X8zFXMaMv+mGww@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dalias@libc.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=musl@lists.openwall.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.