[lkml]   [2020]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH for 5.5 1/2] rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements
----- On Jan 6, 2020, at 2:30 PM, Florian Weimer 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

> 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.



Mathieu Desnoyers
EfficiOS Inc.

 \ /
  Last update: 2020-01-06 21:26    [W:0.061 / U:1.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site