Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbcKZXny (ORCPT ); Sat, 26 Nov 2016 18:43:54 -0500 Received: from mail.kernel.org ([198.145.29.136]:53384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbcKZXno (ORCPT ); Sat, 26 Nov 2016 18:43:44 -0500 MIME-Version: 1.0 From: Paul Turner Date: Sat, 26 Nov 2016 15:43:06 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v8 1/9] Restartable sequences system call To: Pavel Machek Cc: Mathieu Desnoyers , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , LKML , Linux API , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Chris Lameter , Ben Maurer , Steven Rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1648 Lines: 38 On Sat, Aug 27, 2016 at 5:21 AM, Pavel Machek wrote: > > Hi! > >> Expose a new system call allowing each thread to register one userspace >> memory area to be used as an ABI between kernel and user-space for two >> purposes: user-space restartable sequences and quick access to read the >> current CPU number value from user-space. >> >> * Restartable sequences (per-cpu atomics) >> >> Restartables sequences allow user-space to perform update operations on >> per-cpu data without requiring heavy-weight atomic operations. >> >> The restartable critical sections (percpu atomics) work has been started >> by Paul Turner and Andrew Hunter. It lets the kernel handle restart of >> critical sections. [1] [2] The re-implementation proposed here brings a >> few simplifications to the ABI which facilitates porting to other >> architectures and speeds up the user-space fast path. A locking-based >> fall-back, purely implemented in user-space, is proposed here to deal >> with debugger single-stepping. This fallback interacts with rseq_start() >> and rseq_finish(), which force retries in response to concurrent >> lock-based activity. > > Hmm. Purely software fallback needed for singlestepping... Looks like this is malware > writer's dream come true... > > Also if you ever get bug in the restartable code, debugger will be useless to debug it... > unless new abilities are added to debuggers to manually schedule threads on CPUs. > > Is this good idea? We've had some off-list discussion. I have a revised version which incoprorates some of Mattheiu's improvements, but avoids this requirement nearly ready for posting. - Paul