Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756735AbcDHBL4 (ORCPT ); Thu, 7 Apr 2016 21:11:56 -0400 Received: from mail.efficios.com ([78.47.125.74]:49757 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752530AbcDHBLy (ORCPT ); Thu, 7 Apr 2016 21:11:54 -0400 Date: Fri, 8 Apr 2016 01:11:42 +0000 (UTC) From: Mathieu Desnoyers To: Andy Lutomirski , Peter Zijlstra Cc: "Paul E. McKenney" , Ingo Molnar , Paul Turner , Andi Kleen , Chris Lameter , Dave Watson , Josh Triplett , linux-api , linux-kernel@vger.kernel.org, Andrew Hunter , Linus Torvalds Message-ID: <1802683892.49910.1460077902922.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com> <20160407152432.GZ3448@twins.programming.kicks-ass.net> <20160407155312.GA3448@twins.programming.kicks-ass.net> <20160407201156.GC3448@twins.programming.kicks-ass.net> Subject: Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF45 (Linux)/8.6.0_GA_1178) Thread-Topic: restartable sequences v2: fast user-space percpu critical sections Thread-Index: fI0wRM1/G+bVjYjvLo4M4unQjwGWbQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2245 Lines: 68 ----- On Apr 7, 2016, at 6:05 PM, Andy Lutomirski luto@amacapital.net wrote: > On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote: >> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote: [...] >> >>> it's inherently debuggable, >> >> It is more debuggable, agreed. >> >>> and it allows multiple independent >>> rseq-protected things to coexist without forcing each other to abort. [...] My understanding is that the main goal of this rather more complex proposal is to make interaction with debuggers more straightforward in cases of single-stepping through the rseq critical section. I recently came up with a scheme that should allow us to handle such situations in a fashion similar to debuggers handling ll/sc restartable sequences of instructions on e.g. powerpc. The good news is that my scheme does not require anything at the kernel level. The idea is simple: the userspace rseq critical sections now become marked by 3 inline functions (rather than 2 in Paul's proposal): rseq_start(void *rseq_key) rseq_finish(void *rseq_key) rseq_abort(void *rseq_key) We associate each critical section with a unique "key" (dummy 1 byte object in the process address space), so we can group them. The new "rseq_abort" would mark exit points that would exit the critical section without executing the final commit instruction. Within each of rseq_start, rseq_finish and rseq_abort, we declare a non-loadable section that gets populated with the following tuples: (RSEQ_TYPE, insn address, rseq_key) Where RSEQ_TYPE is either RSEQ_START, RSEQ_FINISH, or RSEQ_ABORT. That special section would be found in the executable by the debugger, which can then skip over entire restartable critical sections when it encounters them by placing breakpoints at all exit points (finish and cancel) associated to the same rseq_key as the entry point (start). This way we don't need to complexify the runtime code, neither at kernel nor user-space level, and we get debuggability using a trick similar to what ll/sc architectures already need to do. Of course, this requires extending gdb, which should not be a show-stopper. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com