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

On Fri, 24 Nov 2017, Mathieu Desnoyers wrote:

----- On Nov 23, 2017, at 6:38 PM, Thomas Gleixner tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org wrote:

quoted

You have to test for sys_rseq somewhere in the init code. So you can test
for the other two being fully functional as well.

If one of them is missing then you can avoid that rseq fastpath either
completely or because you never registered that rseq muck your rseq will
just contain stale init data which kicks you into some slowpath fallback
code.

That would work if we could have more than one rseq TLS entry per thread.
If it would be the case, then e.g. lttng-ust could own its own rseq
TLS and do just as you explain above.

It's not the case with the current proposal. This means multiple user
libraries will have to share the same cpu_id and cpu_id_start fields,
which breaks your proposed new-app/old-kernel backward compatibility
check proposal.

For instance, if glibc librseq.so happily registers rseq (and does not
care about testing for cpu_opv or membarrier availability), then
lttng-ust cannot leave stale rseq init data which kicks in its slowpath
fallback.

You have to make sure that _ALL_ prerequisites are there before you start
using it whether you have a shared rseq or not. If a setup has rseq working
and sysops are blocked by a stupid mistake in a security filter, then your
assumption of testing rseq alone is broken already and stuff will explode
in hard to debug ways.

You CANNOT make such assumptions ever. Robustness is the first thing to
look at and after that you can optimize the hell out of it, without
violating robustness while doing that.

Thanks,

	tglx