Linux: implementation incorrectly returns errors on large buffers

[josephlr]

If the buffer passed to the Linux getrandom(2) system call is longer than 256 bytes, the buffer can be partially written. This happens when the system call is interrupted, which becomes more likely the longer the buffer is.

The current implementation returns an error in this case, when it should just try the call again, attempting to fill the remainder of the buffer.

Thanks to @briansmith's ring implementation, for pointing this out.

[dhardy]

We used to have specific handling for interruptions, but at a higher level (in the Rand lib), so the code this descends from just forwarded the error. But I agree, it makes more sense to retry within getrandom now.

[newpavlov]

We have discussed it as part of error-handling story, one possible solution is to add is_retryable method to the Error type and Error::ITERRUPTED constant, so users will be able to re-try if needed.

I am not sure if unconditionally retrying on EINTR is a correct approach. I am not very knowledgeable on signal handling, but IIRC if signal handler returns the SA_RESTART flag syscall gets restarted automatically without returning EINTR.

[josephlr]

I am not sure if unconditionally retrying on EINTR is a correct approach. I am not very knowledgeable on signal handling, but IIRC if signal handler returns the SA_RESTART flag syscall gets restarted automatically without returning EINTR.

Not all signal handlers have to do this, and it seems like in std Rust just retries blocking operations when it gets EINTR, both for RNG and mos syscalls in general. As getrandom() presents a blocking API, retrying on EINTR seems correct.