Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool

[Stephan Mueller]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/