On Fri, 24 Nov 2017, Mathieu Desnoyers wrote: > ----- On Nov 23, 2017, at 6:38 PM, Thomas Gleixner tglx@xxxxxxxxxxxxx wrote: > > 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 -- 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
