----- On Jan 6, 2020, at 2:30 PM, Florian Weimer fw@xxxxxxxxxxxxx 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 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
