----- On Jul 27, 2018, at 6:01 PM, Pavel Machek pavel@xxxxxx wrote: > Hi! > >> 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@xxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
