[3/5] hwrng: core - Do not register device opportunistically

528367 diff mbox series

Currently we only register the device when a valid RNG is added.
However the way it's done is buggy because we test whether there
is a current RNG to determine whether we need to register.  As
the current RNG may be missing due to a reinitialisation error
this can lead to a reregistration of the device.

As the device already has to handle a NULL current RNG anyway,
let's just register the device always and remove the complexity.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---

 drivers/char/hw_random/core.c |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Herbert Xu <herbert@gondor.apana.org.au> writes:
> Currently we only register the device when a valid RNG is added.
> However the way it's done is buggy because we test whether there
> is a current RNG to determine whether we need to register.  As
> the current RNG may be missing due to a reinitialisation error
> this can lead to a reregistration of the device.
>
> As the device already has to handle a NULL current RNG anyway,
> let's just register the device always and remove the complexity.

Does this break userspace by creating a device which will just return
-ENODEV on read?  Sure, callers *should* handle it...

I far prefer this (simpler) model, though.

Thanks,
Rusty.

>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
>
>  drivers/char/hw_random/core.c |   23 ++++++++++++-----------
>  1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 42827fd..1d342f0 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -372,14 +372,14 @@ static DEVICE_ATTR(rng_available, S_IRUGO,
>  		   NULL);
>  
>  
> -static void unregister_miscdev(void)
> +static void __exit unregister_miscdev(void)
>  {
>  	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_available);
>  	device_remove_file(rng_miscdev.this_device, &dev_attr_rng_current);
>  	misc_deregister(&rng_miscdev);
>  }
>  
> -static int register_miscdev(void)
> +static int __init register_miscdev(void)
>  {
>  	int err;
>  
> @@ -484,12 +484,6 @@ int hwrng_register(struct hwrng *rng)
>  		if (err)
>  			goto out_unlock;
>  		set_current_rng(rng);
> -
> -		err = register_miscdev();
> -		if (err) {
> -			drop_current_rng();
> -			goto out_unlock;
> -		}
>  	}
>  	list_add_tail(&rng->list, &rng_list);
>  
> @@ -530,7 +524,6 @@ void hwrng_unregister(struct hwrng *rng)
>  
>  	if (list_empty(&rng_list)) {
>  		mutex_unlock(&rng_mutex);
> -		unregister_miscdev();
>  		if (hwrng_fill)
>  			kthread_stop(hwrng_fill);
>  	} else
> @@ -540,16 +533,24 @@ void hwrng_unregister(struct hwrng *rng)
>  }
>  EXPORT_SYMBOL_GPL(hwrng_unregister);
>  
> -static void __exit hwrng_exit(void)
> +static int __init hwrng_modinit(void)
> +{
> +	return register_miscdev();
> +}
> +
> +static void __exit hwrng_modexit(void)
>  {
>  	mutex_lock(&rng_mutex);
>  	BUG_ON(current_rng);
>  	kfree(rng_buffer);
>  	kfree(rng_fillbuf);
>  	mutex_unlock(&rng_mutex);
> +
> +	unregister_miscdev();
>  }
>  
> -module_exit(hwrng_exit);
> +module_init(hwrng_modinit);
> +module_exit(hwrng_modexit);
>  
>  MODULE_DESCRIPTION("H/W Random Number Generator (RNG) driver");
>  MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

On Wed, Dec 24, 2014 at 09:59:41AM +1030, Rusty Russell wrote:
>
> Does this break userspace by creating a device which will just return
> -ENODEV on read?  Sure, callers *should* handle it...

If somebody complains we could easily fix this by making open
fail.  In fact, if such applications exist then they're likely
to want to hold onto a reference to the RNG after then open...

Cheers,