This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 16/11/2016 16:02, Torvald Riegel wrote:
> 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.

I would advise against adding another symbol, it only adds complexity
and most likely one interface would be preferable from application
point of view.

Considering portability, why not following current approach from other
OS/libc? User will probably create more highly level interfaces based
underlying facilities, so I see trying to follow current interface
semantics in a non standard interface seems a better approach.

For instance, OpenBSD getentropy seems a to just direct syscall, so
not cancellation handling (src/libexec/<architecture>/ldasm.S).
FreeBSD does not have a similar syscall, but provides a sysctl/KERN_ARND
that does basically the same.  I am not sure about Solaris.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]