On 21/11/2022 16.29, Jason A. Donenfeld wrote:
Cc += linux-api
>
> if (!new_block)
> goto out;
> new_cap = grnd_allocator.cap + num;
> new_states = reallocarray(grnd_allocator.states, new_cap, sizeof(*grnd_allocator.states));
> if (!new_states) {
> munmap(new_block, num * size_per_each);
Hm. This does leak an implementation detail of vgetrandom_alloc(),
namely that it is based on mmap() of that size rounded up to page size.
Do we want to commit to this being the proper way of disposing of a
succesful vgetrandom_alloc(), or should there also be a
vgetrandom_free(void *states, long num, long size_per_each)?
And if so, what color should the bikeshed really have. I.e.,
- does it need to take that size_per_each parameter which the kernel knows
- should it rather take the product so it can for now be a simple alias
for munmap
- should it also have a flags argument just because that's what all
well-behaving syscalls have these days...
Also, should vgetrandom_alloc() take a void *hint argument that
would/could be passed through to mmap() to give userspace some control
over where the memory is located - possibly only in the future, i.e.
insist on it being NULL for now, but it could open the possibility for
adding e.g. VGRND_MAP_FIXED[_NOREPLACE] that would translate to the
corresponding MAP_ flags.
Rasmus
