This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] getrandom system call wrapper [BZ #17252]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 9 Sep 2016 16:28:15 +0200
- Subject: Re: [PATCH v3] getrandom system call wrapper [BZ #17252]
- Authentication-results: sourceware.org; auth=none
- References: <661db778-8110-82b2-2c41-d6195916cbea@redhat.com> <1473430905.30192.5.camel@localhost.localdomain>
On 09/09/2016 04:21 PM, Torvald Riegel wrote:
On Thu, 2016-09-08 at 13:44 +0200, Florian Weimer wrote:
I have made the system call wrapper a cancellation point. (If we
implement the simpler getentropy interface, it would not be a
cancellation point.)
Why did you do that?
I have to, because it can block indefinitely.
Even though the system call is new, and thus can't
have been used in existing code directly, making it a cancellation point
will make all callers cancellation points too. Therefore, for example,
we couldn't use it in the implementation of any POSIX functions (that
are not cancellation points) in glibc without having to disable and
restore the cancellation state around it every time.
The system call definition facility also provides a
__getrandom_notcancel entry point, which can be called if we don't
expect blocking. Obviously, this is for internal use only.
It might be even more convenient to have one wrapper that is a
cancellation point and one that is not.
Can't we just let cancellation rot in its corner?
No, we have many customers who use it (and this despite the fact that
the current implementation has a critical race condition).
Synchronous cancellation is often easier to use than the alternative
because our API does not allow waiting for arbitrary combination of events.
Asynchronous cancellation is not very useful, though.
Thanks,
Florian