Messages in this thread | | | Date | Wed, 23 Nov 2022 09:51:04 +0100 | Subject | Re: [PATCH v6 2/3] random: introduce generic vDSO getrandom() implementation | From | Rasmus Villemoes <> |
| |
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
| |