Am Dienstag, 19. Mai 2015, 15:22:27 schrieb Herbert Xu:
Hi Herbert,
> On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
> > Herbert, do you have any ideas?
>
> On the /dev/random side,
>
> 1) Add a struct module argument in addition to func/data.
> 2) Grab module ref count when func/data is registered.
> 3) Drop module ref count after func returns.
>
> On the drbg side,
>
> 1) Allocate data pointer before func/data registration, it should
> contain a flag indicating whether drbg is still alive.
> 2) In cra_exit, zap the flag in allocated data.
> 3) In func immediately return if flag indicates drbg is dead.
> 4) Free allocated data pointer when func is done.
>
> Obviously you need to add some locking so that func doesn't race
> against cra_exit or any other drbg paths that it intersects.
Thank you for the hints. I will follow your guidance.
Just for my edification: why is this (rather complex sounding) approach
preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls
with io_cancel) have such cancel operations.
Such cancel function would be as simple as:
void get_blocking_random_bytes_cancel(void *private)
{
struct random_work *rw, *tmp;
mutex_lock(&random_wait_list_mutex);
list_for_each_entry_safe(rw, tmp, &random_wait_list, list) {
if (private == rw->rw_private) {
list_del(&rw->list);
kfree(rw);
break;
}
}
mutex_unlock(&random_wait_list_mutex);
}
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
