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

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2016-11-16 at 16:52 +0100, Florian Weimer wrote:
> 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 think it would be better to split the getrandom that is a cancellation
point into two functions, getrandom (not a cancellation point) and
getrandom_cancelable (is a cancellation point).  This way, the
functionality is available for programs but requires explicit opt-in,
while the default is not going to lead to surprises in the expected
common case (ie, when randomness is available).  I don't think the
opt-in is a problem because as you said, cancellation requires careful
programming anyway.