Re: [PATCH for 5.5 1/2] rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements

[Mathieu Desnoyers]

----- On Dec 20, 2019, at 3:37 PM, Florian Weimer fw@xxxxxxxxxxxxx wrote:

> * Mathieu Desnoyers:
> 
>> diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
>> index 9a402fdb60e9..6f26b0b148a6 100644
>> --- a/include/uapi/linux/rseq.h
>> +++ b/include/uapi/linux/rseq.h
>> @@ -100,7 +100,9 @@ struct rseq {
>>  	 * instruction sequence block, as well as when the kernel detects that
>>  	 * it is preempting or delivering a signal outside of the range
>>  	 * targeted by the rseq_cs. Also needs to be set to NULL by user-space
>> -	 * before reclaiming memory that contains the targeted struct rseq_cs.
>> +	 * before reclaiming memory that contains the targeted struct rseq_cs
>> +	 * or reclaiming memory that contains the code refered to by the
>> +	 * start_ip and post_commit_offset fields of struct rseq_cs.
> 
> Maybe mention that it's good practice to clear rseq_cs before
> returning from a function that contains a restartable sequence?

Unfortunately, clearing it is not free. Considering that rseq is meant to
be used in very hot code paths, it would be preferable that applications
clear it in the very infrequent case where the rseq_cs or code will
vanish (e.g. dlclose or JIT reclaim), and not require it to be cleared
after each critical section. I am therefore reluctant to document the
behavior you describe as a "good practice" for rseq.

> That will deal with the dlclose issue because even if the function
> calls dlclose itself, unmapping something on call stack for dlclose is
> already undefined.

It would, but at the cost of adding an extra NULL store on pretty much
every use of rseq (think memory allocator fast-path for instance).

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com