From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751472AbdKVTdE (ORCPT ); Wed, 22 Nov 2017 14:33:04 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:52052 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751260AbdKVTdC (ORCPT ); Wed, 22 Nov 2017 14:33:02 -0500 Date: Wed, 22 Nov 2017 20:32:19 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: 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 , Will Deacon , Michael Kerrisk Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op vector Message-ID: <20171122193219.GI3165@worktop.lehotels.local> References: <20171121141900.18471-1-mathieu.desnoyers@efficios.com> <20171121172144.GL2482@two.firstfloor.org> <740195164.19702.1511301908907.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <740195164.19702.1511301908907.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op vector Date: Wed, 22 Nov 2017 20:32:19 +0100 Message-ID: <20171122193219.GI3165@worktop.lehotels.local> References: <20171121141900.18471-1-mathieu.desnoyers@efficios.com> <20171121172144.GL2482@two.firstfloor.org> <740195164.19702.1511301908907.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <740195164.19702.1511301908907.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mathieu Desnoyers Cc: 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 , Will List-Id: linux-api@vger.kernel.org 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.