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

[Torvald Riegel <triegel@redhat.com>]

On Fri, 2016-09-09 at 16:28 +0200, Florian Weimer wrote:
> 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.

That doesn't mean you have to make the default function a cancellation
point.  There are many POSIX functions which can block indefinitely and
which are not required to be cancellation points (eg, rwlocks only *may*
be cancellation points).

Can the system call really block indefinitely, or only for a long time
and (ie, will return eventually)?

> > 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).

Usage of it doesn't mean that it has to be the default.  Have we made
other syscall wrappers cancellation points in the past (ie, syscalls
that don't already have a matching POSIX function that is specified to
be a cancellation point too)?

I'm worried about people who just want to use the syscall but don't know
that much about POSIX cancellation.  They couldn't use the syscall
safely in a library without also being aware of POSIX cancellation, and
I'm concerned that they might just forget to disable cancellation around
the syscall, thus creating resource leaks, deadlocks (eg, cancellation
handler doesn't release locks), etc.  If this is primarily a Linux API
currently (ignoring the Solaris case for a while), then marrying it to
POSIX seems wrong.