From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@kernel.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: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers
Date: Wed, 9 Mar 2016 13:26:44 -0800 [thread overview]
Message-ID: <CA+55aFxHyKwu4RnP2AU5YDtzmNGvQZvywYZg1iJWQsJt4VvJqA@mail.gmail.com> (raw)
In-Reply-To: <CALCETrXXx36buZyOhnYu-N3boRrCdK0a8p8yPHD+te1k3zYY=Q@mail.gmail.com>
On Wed, Mar 9, 2016 at 12:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> How safe would this be in a multithreaded process? For example, if
> open() gets canceled in the "killable" sense, is it guaranteed that no
> file descriptor will be allocated?
Not all system calls can be killed, we only do the usual cases. A
system call has to have the proper EINTR logic in place, so it's not
like we kill system calls at any random point.
> Let me try to summarize my understanding of the semantics.
>
> Thread A sends thread B a signal. Thread B wants to ignore the signal
> and defer handling unless it's either in a particular syscall and
> returns -EINTR or unless the thread is about to do the syscall.
Note that for the kernel, we don't actually have to use a signal for
this at all. Our existing "cancel system calls" code only works for
fatal signals, but that's just a trivial implementation issue.
We could add a system call that just sets a cancel flag in another
thread, and we'd just use that cancel flag to say "abort the currently
executing system call with EINTR" - in all the same places we
currently dot hat "fatal_signal_pending()" thing.
You'd still have to have all the user-space logic to do the
cancellation cleanup etc. But now you could actually cancel a write()
system call in the *middle*, which is currently just not an option.
Linus
next prev parent reply other threads:[~2016-03-09 21:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 1:24 Andy Lutomirski
2016-03-09 8:56 ` Ingo Molnar
2016-03-09 11:34 ` Szabolcs Nagy
2016-03-09 11:40 ` Szabolcs Nagy
2016-03-09 19:47 ` [musl] " Linus Torvalds
2016-03-09 20:57 ` Andy Lutomirski
2016-03-09 21:26 ` Linus Torvalds [this message]
2016-03-10 10:57 ` Ingo Molnar
2016-03-10 3:34 ` [musl] " 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 ` [musl] " Rich Felker
2016-03-11 0:18 ` Szabolcs Nagy
2016-03-11 0:48 ` [musl] " 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 ` [musl] " Rich Felker
2016-03-11 9:33 ` Ingo Molnar
2016-03-11 11:39 ` Szabolcs Nagy
2016-03-11 19:27 ` Linus Torvalds
2016-03-11 19:30 ` [musl] " 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 ` [musl] " Rich Felker
2016-03-12 17:00 ` Ingo Molnar
2016-03-12 18:05 ` [musl] " Rich Felker
2016-03-12 18:48 ` Ingo Molnar
2016-03-12 19:08 ` [musl] " 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+55aFxHyKwu4RnP2AU5YDtzmNGvQZvywYZg1iJWQsJt4VvJqA@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).