From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753406AbdKWVOO (ORCPT ); Thu, 23 Nov 2017 16:14:14 -0500 Received: from mail.efficios.com ([167.114.142.141]:33781 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752150AbdKWVOL (ORCPT ); Thu, 23 Nov 2017 16:14:11 -0500 Date: Thu, 23 Nov 2017 21:15:21 +0000 (UTC) From: Mathieu Desnoyers To: Will Deacon Cc: Peter Zijlstra , Andi Kleen , "Paul E. McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Michael Kerrisk Message-ID: <165707648.21250.1511471721845.JavaMail.zimbra@efficios.com> In-Reply-To: <20171122193734.GO22648@arm.com> References: <20171121141900.18471-1-mathieu.desnoyers@efficios.com> <20171121172144.GL2482@two.firstfloor.org> <740195164.19702.1511301908907.JavaMail.zimbra@efficios.com> <20171122193219.GI3165@worktop.lehotels.local> <20171122193734.GO22648@arm.com> Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op vector MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.141] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF52 (Linux)/8.7.11_GA_1854) Thread-Topic: Restartable sequences and CPU op vector Thread-Index: D70vTZwHWVHlwvBsgR+k4pxCbr+IJA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Nov 22, 2017, at 2:37 PM, Will Deacon will.deacon@arm.com wrote: > On Wed, Nov 22, 2017 at 08:32:19PM +0100, Peter Zijlstra wrote: >> On Tue, Nov 21, 2017 at 10:05:08PM +0000, Mathieu Desnoyers wrote: >> > Other than that, I have not received any concrete alternative proposal to >> > properly handle single-stepping. >> >> That's not entirely true; amluto did have an alternative in Prague: do >> full machine level instruction emulation till the end of the rseq when >> it gets 'preempted too often'. >> >> Yes, implementing that will be an absolute royal pain. But it does >> remove the whole duplicate/dual program asm/bytecode thing and avoids >> the syscall entirely. >> >> And we don't need to do a full x86_64/arch-of-choice emulator for this >> either; just as cpu_opv is fairly limited too. We can do a subset that >> allows dealing with the known sequences and go from there -- it can >> always fall back to not emulating and reverting to the pure rseq with >> debug/fwd progress 'issues'. >> >> So what exactly is the problem of leaving out the whole cpu_opv thing >> for now? Pure rseq is usable -- albeit a bit cumbersome without >> additional debugger support. > > Drive-by "ack" to that. I'd really like a working rseq implementation in > mainline, but I don't much care for another interpreter. Considering the arm 64 use-case of reading PMU counters from user-space using rseq to prevent migration, I understand that you're lucky enough to already have a system call at your disposal that can perform the slow-path in case of single-stepping. So yes, your particular case is already covered, but unfortunately that's not the same situation for other use-cases that have been expressed. Thanks, Mathieu > > Will -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com