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 17/11/16 17:16, Zack Weinberg wrote:
> On 11/17/2016 10:24 AM, Florian Weimer wrote:
>> On 11/17/2016 02:56 PM, Zack Weinberg wrote:
>>> Also evidence that making getrandom a
>>> cancellation point _won't_ break programs that naively assume it can
>>> never fail.
>>
>> Cancellation does not add additional error return cases.
>
> It does add additional _failure_ cases. Suppose a program that expects
> threads only to be at risk of cancellation at points where they do
> network I/O, and does all the necessary dancing to make that reliable.
> These threads are _already_ using getrandom() where available, via a
> portability wrapper that will call into the C library if possible, or
> make a direct syscall otherwise. Being a wrapper, it's not a
> cancellation point, and the surrounding code relies on that. Now you
> upgrade glibc, and suddenly getrandom() _is_ a cancellation point, and
> the threads can now be cancelled in places where their data structures
> are internally inconsistent -- and it doesn't matter that getrandom()
> doesn't block under normal conditions, because the generic
> cancel-testing code will fire anyway.
>
> [This is just the general argument that adding new cancellation points
> to the C library can render existing code buggy without notice.]
there is no existing code that uses glibc getrandom.
a user can easily turn a cancellation point into
a non-cancellation one if desired, but the other
way is not possible.
blocking syscalls have to be cancellation points
otherwise they cannot be called safely from a long
running process that has to remain responsive:
blocked threads can keep piling up and there is no
way to reuse the resources they hold.
[this is the general argument for adding new
blocking syscalls as cancellation points].