Restartable sequences in glibc

Posted Feb 1, 2022 1:26 UTC (Tue) by developer122 (guest, #152928)
Parent article: Restartable sequences in glibc

In the case of nested restartable sequences, what would even be the correct behavior? If sequence A called into code that started sequence B, and an interruption occurred during B, should we jump to A's interruption vector or B's? Technically, they were BOTH interrupted, but the failure of B is part of the failure of A? So we should jump to A's vector?

Restartable sequences in glibc

Posted Feb 1, 2022 1:51 UTC (Tue) by compudj (subscriber, #43335) [Link] (2 responses)

There is no such thing as nested restartable sequences. A rseq c.s. cannot issue a function call that moves the instruction pointer outside of the critical section range.

Please keep in mind that this is user-space code, so interrupt handlers don't really make sense in this context. What happens when a signal is delivered on top of a rseq critical section is very much relevant though.

What happens in this case is that the rseq c.s. interrupted by the signal handler will be aborted (it's instruction pointer moved to the abort_ip) so when the signal handler returns, the interrupted thread will continue its execution at the abort ip. It's pretty much as simple as that.

This allows using rseq critical sections within signal handlers as well.

Restartable sequences in glibc

Posted Feb 1, 2022 16:10 UTC (Tue) by developer122 (guest, #152928) [Link] (1 responses)

I'm thinking in terms of code that may itself make use this restartible sequences feature, within a restartable sequence. It would be a linear sequence of code, but there may be a subtask of one atomic sequence that itself makes the most sense to implement as an atomic sequence. I have a hard time imagining such a senario (why not just handle cleanup for both sequences as part of the code at the outer sequence's cleanup vector, and omit the inner sequence's guards?) but I wouldn't be surprised if such a case existed.

As for how such a situation could ever occur, the article mentions calling code that makes use of restartible sequences, which I suppose could be inlined. So, one bit of restartible code could call a data manipulation library that itself naively tried to create a restartible sequence to protect it's own data structures. Each is trying to protect it's manipulation of it's data structures from access during premption by discarding results that were being worked on if a premption occurred.

The tricky thing here is the matter of cleanup. If something interrupts both sequences by occuring during the nested sequence, then you could restart just the inner sequence but that's wrong because the outer sequence is interrupted and doesn't know it. BUT, if you run just out outer sequence's cleanup code, then the data structures for the inner sequence may be left in an indeterminate state with the changes not being discarded. You can't run both, because only the entry not the exit is defined.

And while we're at it, we're invented the C++ problem of memory cleanup :/

Restartable sequences in glibc

Posted Feb 1, 2022 16:24 UTC (Tue) by compudj (subscriber, #43335) [Link]

The code for a restartable sequence critical section sits squarely within a single inline asm. So there is no way one could "call" a data manipulation library from the inline asm without an explicit call, which would move the instruction pointer outside of the critical section, and is not at all a supported use-case.

So I really don't think the scenario you have in mind can realistically happen with the current rseq ABI.