From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753921AbcCJQlZ (ORCPT ); Thu, 10 Mar 2016 11:41:25 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:51665 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753059AbcCJQlQ (ORCPT ); Thu, 10 Mar 2016 11:41:16 -0500 Date: Thu, 10 Mar 2016 11:41:05 -0500 From: Rich Felker To: Ingo Molnar Cc: Linus Torvalds , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , "musl@lists.openwall.com" , Andrew Morton , Thomas Gleixner , Peter Zijlstra Subject: Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Message-ID: <20160310164104.GM9349@brightrain.aerifal.cx> References: <06079088639eddd756e2092b735ce4a682081308.1457486598.git.luto@kernel.org> <20160309085631.GA3247@gmail.com> <20160309113449.GZ29662@port70.net> <20160310033446.GL9349@brightrain.aerifal.cx> <20160310111646.GA13102@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160310111646.GA13102@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 10, 2016 at 12:16:46PM +0100, Ingo Molnar wrote: > > * Rich Felker 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? This still doesn't address the issue that the code making the syscall needs to be able to control whether it's cancellable or not. Not only do some syscalls whose public functions are cancellation points need to be used internally in non-cancellable ways; there's also the pthread_setcancelstate interface that allows deferring cancellation so that it's possible to call functions which are cancellation points without invoking cancellation. Ideally all syscalls would be like pselect/ppoll and take a sigset_t to unmask/remask atomically with respect to the syscall action. Then implementing cancellation (as well as using EINTR race-free) would be trivial. But this is obviously not a practical change to make. >>From my standpoint the simplest and cleanest solution is for vdso to provide a predicate function that takes a ucontext_t and returns true/false for whether it represents a state prior to entering (or reentering, for restart state) the vdso syscall. If vdso exports this symbol libc can use vdso syscall with cancellation. If not, it can just fallback to straight inline syscall like now. Rich