From: Rusty Russell <rusty@rustcorp.com.au>
To: Herbert Xu <herbert@gondor.apana.org.au>,
Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
linux-kernel@vger.kernel.org,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Amos Kong <akong@redhat.com>,
m@bues.ch, mpm@selenic.com, amit.shah@redhat.com
Subject: Re: [PATCH 3/5] hwrng: core - Do not register device opportunistically
Date: Wed, 24 Dec 2014 09:59:41 +1030 [thread overview]
Message-ID: <87mw6egd22.fsf@rustcorp.com.au> (raw)
In-Reply-To: <E1Y3ICh-0007d7-SM@gondolin.me.apana.org.au>
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");
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: lkp@lists.01.org
Subject: Re: [PATCH 3/5] hwrng: core - Do not register device opportunistically
Date: Wed, 24 Dec 2014 09:59:41 +1030 [thread overview]
Message-ID: <87mw6egd22.fsf@rustcorp.com.au> (raw)
In-Reply-To: <E1Y3ICh-0007d7-SM@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]
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");
next prev parent reply other threads:[~2014-12-26 0:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 3:09 [hwrng] WARNING: CPU: 0 PID: 1 at include/linux/kref.h:47 set_current_rng() Fengguang Wu
2014-12-23 3:09 ` Fengguang Wu
2014-12-23 5:39 ` [0/5] hwrng: Fix kref warning and underlying bugs Herbert Xu
2014-12-23 5:39 ` Herbert Xu
2014-12-23 5:40 ` [PATCH 1/5] hwrng: core - Use struct completion for cleanup_done Herbert Xu
2014-12-23 5:40 ` Herbert Xu
2014-12-23 23:19 ` Rusty Russell
2014-12-23 23:19 ` Rusty Russell
2014-12-23 5:40 ` [PATCH 2/5] hwrng: core - Fix current_rng init/cleanup race yet again Herbert Xu
2014-12-23 5:40 ` Herbert Xu
2014-12-23 23:26 ` Rusty Russell
2014-12-23 23:26 ` Rusty Russell
2014-12-26 0:52 ` Herbert Xu
2014-12-26 0:52 ` Herbert Xu
2014-12-23 5:40 ` [PATCH 3/5] hwrng: core - Do not register device opportunistically Herbert Xu
2014-12-23 5:40 ` Herbert Xu
2014-12-23 23:29 ` Rusty Russell [this message]
2014-12-23 23:29 ` Rusty Russell
2014-12-26 1:00 ` Herbert Xu
2014-12-26 1:00 ` Herbert Xu
2014-12-23 5:40 ` [PATCH 4/5] hwrng: core - Drop current rng in set_current_rng Herbert Xu
2014-12-23 5:40 ` Herbert Xu
2014-12-23 5:40 ` [PATCH 5/5] hwrng: core - Move hwrng_init call into set_current_rng Herbert Xu
2014-12-23 5:40 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mw6egd22.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akong@redhat.com \
--cc=amit.shah@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=m@bues.ch \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.