* 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.
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.
----- On Jan 6, 2020, at 2:30 PM, Florian Weimer fw@deneb.enyo.de wrote:
* Mathieu Desnoyers:
quoted
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