----- On Nov 21, 2017, at 12:21 PM, Andi Kleen andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org wrote:

On Tue, Nov 21, 2017 at 09:18:38AM -0500, Mathieu Desnoyers wrote:

quoted

Hi,

Following changes based on a thorough coding style and patch changelog
review from Thomas Gleixner and Peter Zijlstra, I'm respinning this
series for another RFC.

My suggestion would be that you also split out the opv system call.
That seems to be main contention point currently, and the restartable
sequences should be useful without it.

I consider rseq to be incomplete and a pain to use in various scenarios
without cpu_opv. 

About the contention point you refer to:

Using vDSO as an example of how things should be done is just wrong: the
vDSO interaction with debugger instruction single-stepping is broken,
as I detailed in my previous email.

Thomas' proposal of handling single-stepping with a user-space locking
fallback, which is pretty much what I had in 2016, pushes a lot of
complexity to user-space, requires an extra branch in the fast-path,
as well as additional store-release/load-acquire semantics for consistency.
I don't plan going down that route.

Other than that, I have not received any concrete alternative proposal to
properly handle single-stepping.

The only opposition against cpu_opv is that there *should* be an hypothetical
simpler solution. The rseq idea is not new: it's been presented by Paul Turner
in 2012 at LPC. And so far, cpu_opv is the overall simplest and most
efficient way I encountered to handle single-stepping, and it gives extra
benefits, as described in my changelog.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com