* Mathieu Desnoyers: > If we extend struct rseq to a size that makes the compiler use an > alignment larger than 32 bytes in the future, and if the compiler uses > that larger alignment knowledge to issue instructions that require the > larger alignment, then it would be incorrect for user-space to > allocate the struct rseq on an alignment lower than the required > alignment. > > Indeed, on rseq registration, we have the following check: > > if (!IS_ALIGNED((unsigned long)rseq, __alignof__(*rseq)) > [...] > return -EINVAL; > > Which would break if the size of struct rseq is large enough that the > alignment grows larger than 32 bytes. I never quite understood the reason for that check, it certainly made the glibc implementation more complicated. But to support variable sizes internally, we'll have to put in some extra effort anyway, so that it won't matter much in the end. As long as the required alignment isn't larger than the page size. 8-/ > You mentioned we could steal some high bits from AT_RSEQ_FEATURE_SIZE > to put the alignment. What is the issue with exposing an explicit > AT_RSEQ_ALIGN ? It's just a auxv entry, so I don't see it as a huge > performance concern to access 2 entries rather than one. I don't mind too much, we already have a large on-stack array in the loader so that we can decode the auxiliary vector without a humongous switch statement. But eventually that approach will stop working if the set of interesting AT_* values become too large and discontinuous. Thanks, Florian
