----- On Jan 6, 2020, at 2:30 PM, Florian Weimer fw@deneb.enyo.de wrote:
- Mathieu Desnoyers:
Just to clarify: should the discussion here prevent the UAPI documentation change from being merged into the Linux kernel ? Our discussion seems to be related to integration of rseq into glibc, rather than the kernel UAPI per se.
I still think that clearing rseq_cs upon exit from the function that contains the sequence is good practice, and the UAPI header should mention that.
My understanding is that a UAPI header should document what is strictly required (here, clearing rseq_cs before unmapping the memory area containing the rseq_cs structure or the code). Documenting a "best practice" would AFAIU belong to a man page and not a UAPI header.
I'm adding Michael Kerrisk in CC in case he has an opinion on this matter.
For glibc, if I recall correctly, we decided against doing anything in dlclose to deal with this issue (remapping new code in an existing rseq area) because it would need updating all threads, not just the thread calling dlclose. That's why we're punting this to applications and why I think the UAPI header should mention this.
Nothing prevents us from implementing a clever scheme in the future, e.g. as a new membarrier command, that could be invoked from dlclose() when it becomes available.
By documenting only the basic requirement in the UAPI header (do not use-after-free) and not providing a "best practice" (which is not so good performance-wise), we can then let the man page state the best practices, and update them as new system call commands are implemented.
Thanks,
Mathieu