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
Date: Thu, 10 Mar 2016 12:16:46 +0100 [thread overview]
Message-ID: <20160310111646.GA13102@gmail.com> (raw)
In-Reply-To: <20160310033446.GL9349@brightrain.aerifal.cx>
* Rich Felker <dalias@libc.org> wrote:
> [...]
>
> I believe a new kernel cancellation API with a sticky cancellation flag (rather
> than a signal), and a flag or'd onto the syscall number to make it cancellable
> at the call point, could work, but then userspace needs to support fairly
> different old and new kernel APIs in order to be able to run on old kernels
> while also taking advantage of new ones, and it's not clear to me that it would
> actually be worthwhile to do so. I could see doing it for a completely new
> syscall API, but as a second syscall API for a system that already has one it
> seems gratuitous. From my perspective the existing approach (checking program
> counter from signal handler) is very clean and simple. After all it made enough
> sense that I was able to convince the glibc folks to adopt it.
I concur with your overall analysis, but things get a bit messy once we consider
AT_SYSINFO which is a non-atomic mix of user-space and kernel-space code. Trying
to hand cancellation status through that results in extra complexity:
arch/x86/entry/vdso/Makefile | 3 +-
arch/x86/entry/vdso/vdso32/cancellation_helpers.c | 116 ++++++++++++++++++++++
arch/x86/entry/vdso/vdso32/vdso32.lds.S | 2 +
tools/testing/selftests/x86/unwind_vdso.c | 57 +++++++++--
4 files changed, 171 insertions(+), 7 deletions(-)
So instead of a sticky cancellation flag, we could introduce a sticky cancellation
signal.
A 'sticky signal' is not cleared from signal_pending() when the signal handler
executes, but it's automatically blocked so no signal handler recursion occurs.
(A sticky signal could still be cleared via a separate mechanism, by the
cancellation cleanup code.)
Such a 'sticky cancellation signal' would, in the racy situation, cause new
blocking system calls to immediately return with -EINTR. Non-blocking syscalls
could still be used. (So the cancellation signal handler itself would still have
access to various fundamental system calls.)
I think this would avoid messy coupling between the kernel's increasingly more
varied system call entry code and C libraries.
Sticky signals could be requested via a new SA_ flag.
What do you think?
Thanks,
Ingo
next prev parent reply other threads:[~2016-03-10 11:16 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 [this message]
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
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=20160310111646.GA13102@gmail.com \
--to=mingo@kernel.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=musl@lists.openwall.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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.