This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
On Mon, 2016-11-21 at 12:12 -0500, Zack Weinberg wrote:
> On Mon, Nov 21, 2016 at 11:57 AM, Torvald Riegel <triegel@redhat.com> wrote:
> > On Fri, 2016-11-18 at 13:50 -0500, Zack Weinberg wrote:
> >> I don't want to derail this into a general debate over adding new
> >> cancellation points, and I especially don't want to hold up work on a
> >> user-space CSPRNG on something unrelated, because arc4random() is the
> >> top item on _my_ todo list after explicit_bzero(). So here is a
> >> counterproposal. Most of my concerns about getrandom() being a
> >> cancellation point go away if it is only a cancellation point when it
> >> is actually going to block
> >
> > Is there a way for the caller to ensure that a subsequent call to
> > getrandom is not going to block? If there isn't, then the caller has to
> > conservatively assume that the call may be a cancellation point.
>
> The whole reason I can live with my proposal is that most code should
> be able to assume getrandom *never* blocks. Specifically, if
> getrandom ever blocks once we're past a fairly early stage of boot-up,
> that's a bug in either the kernel or the setup procedure.
Does the kernel guarantee this, meaning that it's specifically
documented as part of the interface? Or similarly, does it give a
guarantee under some precondition (which systemd or similar guarantees
to establish)?
I understand why you think this would be useful behavior, but the
"should be able" part in your statement is too vague for us to rely on.
Also, what do you mean specifically by "block"? If it is just taking a
relatively long time, but will always eventually finish irrespective of
whether other processes do or do not do something, then I wouldn't
classify the behavior as blocking.