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

[Torvald Riegel]

On Fri, 2016-11-18 at 13:50 -0500, Zack Weinberg wrote:
> I don't want to derail this into a general debate over adding new
> cancellation points, and I especially don't want to hold up work on a
> user-space CSPRNG on something unrelated, because arc4random() is the
> top item on _my_ todo list after explicit_bzero().  So here is a
> counterproposal.  Most of my concerns about getrandom() being a
> cancellation point go away if it is only a cancellation point when it
> is actually going to block

Is there a way for the caller to ensure that a subsequent call to
getrandom is not going to block?  If there isn't, then the caller has to
conservatively assume that the call may be a cancellation point.

I still think something like 
ssize_t getrandom (/*getrandom parameters*/, bool cancellation_point);  
would probably be the best option because it requires a caller to make a
conscious decision about cancellation (and thus also makes the caller
aware of the whole cancellation thing).