[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <165707648.21250.1511471721845.JavaMail.zimbra@efficios.com>
Date: Thu, 23 Nov 2017 21:15:21 +0000 (UTC)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Will Deacon <will.deacon@....com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Boqun Feng <boqun.feng@...il.com>,
Andy Lutomirski <luto@...capital.net>,
Dave Watson <davejwatson@...com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-api <linux-api@...r.kernel.org>,
Paul Turner <pjt@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King <linux@....linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Andrew Hunter <ahh@...gle.com>,
Chris Lameter <cl@...ux.com>, Ben Maurer <bmaurer@...com>,
rostedt <rostedt@...dmis.org>,
Josh Triplett <josh@...htriplett.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op
vector
----- On Nov 22, 2017, at 2:37 PM, Will Deacon will.deacon@....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
Powered by blists - more mailing lists