Re: [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11

[Mathieu Desnoyers]

----- On Nov 14, 2017, at 4:15 PM, Andy Lutomirski luto@xxxxxxxxxxxxxx wrote:

> On Tue, Nov 14, 2017 at 1:08 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Tue, Nov 14, 2017 at 12:03 PM, Mathieu Desnoyers
>> <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>>> Here is the last RFC round of the updated rseq patchset containing:
>>
>> Andy? You were the one with concerns here and said you'd have
>> something else ready for comparison.
>>
> 
> I had a long discussion with Mathieu and KS and I think that this is a
> good compromise.  I haven't reviewed the series all that carefully,
> but I think the idea is sound.
> 
> Basically, event_counter is gone (to be re-added in a later kernel if
> it really ends up being necessary, but it looks like it may primarily
> be a temptation to write subtly incorrect user code and to see
> scheduling details that shouldn't be readily exposed rather than a
> genuinely useful feature) and the versioning mechanism for the asm
> critical section bit is improved.  My crazy proposal should be doable
> on top of this if there's demand and if anyone wants to write the
> gnarly code involved.
> 
> IOW no objection from me as long as those changes were made, which I
> *think* they were.  Mathieu?

Yes, I applied all your suggestions.

The major change was removal of the event_counter. I did improve the
user-space side of things significantly, both in terms of speed, and
reduced complexity, as the rseq and cpu_opv C code is now very much
alike. We could even have a library header macro that would ensure both
fast and slow paths are the same.

I added the version field to struct rseq_cs. Along with the "rseq_len"
parameter to sys_rseq for the struct rseq, we should be good to handle
future extensions.

One thing I kept however that diverge from your recommendation is the
"sign" parameter to the rseq syscall. I prefer this flexible
approach to a hardcoded signature value. We never know when we may
need to randomize or change this in the future.

Regarding abort target signature the vs x86 disassemblers, I used a
5-byte no-op on x86 32/64:

  x86-32: nopl <sig>
  x86-64: nopl <sig>(%rip)

Other architectures (e.g. arm32, powerpc 32/64) with fixed-size instruction
set don't need this kind of trick to make disassemblers happy. Actually,
it is common practice on e.g. arm 32 to put literal values after branch
instructions so they are close to the load instruction.

Those were all the action items I had gathered following our discussion
at KS. Let me know if I'm missing anything.

Thanks,

Mathieu

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