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 v3] getrandom system call wrapper [BZ #17252]

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.


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