[PATCH v7] getrandom system call wrapper [BZ #17252]

[Florian Weimer]

On 11/16/2016 04:20 PM, Zack Weinberg wrote:
> On 11/16/2016 10:11 AM, Florian Weimer wrote:
>> On 11/14/2016 07:29 PM, Zack Weinberg wrote:
>>> On 11/14/2016 12:44 PM, Florian Weimer wrote:
>>>> This patch switches back to the ssize_t return time.  This goes against
>>>> Theodore Ts'o preference, but seems to reflect the consensus from the
>>>> largery community.
>>>
>>> I still don't think this function should be a cancellation point.
>>
>> I guess we'll have to agree to disagree on this matter.
>
> I am seriously considering escalating my disagreement here to a formal
> objection.  I would like to know why you think it is NECESSARY - not
> merely convenient or consistent with other stuff - for this function to
> be a cancellation point.

It's necessary if you ever want to cancel a hanging getrandom in a 
context where you cannot install a signal handler (so that you can 
trigger EINTR when getrandom is stuck).

I really don't understand why cancellation points are widely considered 
as evil.  Most code does not use cancellation in a correct way, and it 
will not improve if we simply stop adding new cancellation points. 
Furthermore, it's easy to make a cancellation point go away (just switch 
the cancel state around the call), but at least in library code, it is 
impossible to introduce cancellation into a system call where the 
wrapper does not support it (because you cannot fake your own version of 
cancellation with a do-nothing signal handler).

Thanks,
Florian