Re: [RFC PATCH for 4.18 00/16] Restartable Sequences

----- On Jul 27, 2018, at 6:01 PM, Pavel Machek pavel@ucw.cz wrote:

Hi!

quoted

So for instance, this turns:

  int cpu = rseq_per_cpu_lock(lock, target_cpu);
  [...]
  rseq_per_cpu_unlock(lock, cpu);

into

  int cpu = rseq_this_cpu_lock(lock);
  [...]
  rseq_per_cpu_unlock(lock, cpu);

and:

  per_cpu_list_push(list, node, target_cpu);
  [...]
  per_cpu_list_pop(list, node, target_cpu);

into

  this_cpu_list_push(list, node, &cpu);  /* cpu is an output parameter. */
  [...]
  node = this_cpu_list_pop(list, &cpu);  /* cpu is an output parameter. */

Eventually integrating cpu_opv or some alternative will allow passing
the cpu number as parameter rather than requiring the algorithm to work
on the current CPU.

The second effect of not having the cpu_opv fallback is that
line and instruction single-stepping with a debugger transforms rseq
critical sections based on retry loops into never-ending loops.
Debuggers need to use the __rseq_table section to skip those critical
sections in order to correctly behave when single-stepping a thread
which uses rseq in a retry loop. However, applications which use an
alternative fallback method rather than retrying on rseq fast-path abort
won't be affected by this kind of single-stepping issue.

Thanks for your feedback!

Would it make sense to include Documentation/ patch? I guess at least
manpage describing the syscall will be needed....

Hi Pavel,

Documentation-wise, I have posted a rseq man page rfc here:

https://lkml.kernel.org/r/20180616195803.29877-1-mathieu.desnoyers@efficios.com

comments are welcome!

It does not include any details about user-space library APIs though, as
this is not the purpose of the syscall documentation.

We're currently discussing integration of rseq thread registration into
glibc.

Once this is settled, I plan to provide a librseq which will contain headers
and documentation on how to use rseq without having to re-create the low-level
assembly every time.

Does this plan make sense to you ?

Thanks,

Mathieu

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