From: Amos Kong <akong@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: m@bues.ch, kvm@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, mb@bu3sch.de,
mpm@selenic.com, amit.shah@redhat.com,
herbert@gondor.apana.org.au
Subject: Re: [PATCH v4 4/6] hw_random: fix unregister race.
Date: Tue, 25 Nov 2014 15:42:23 +0800 [thread overview]
Message-ID: <20141125074223.GA11690@air.redhat.com> (raw)
In-Reply-To: <87y4rhm5fv.fsf@rustcorp.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 2418 bytes --]
On Wed, Nov 12, 2014 at 02:33:00PM +1030, Rusty Russell wrote:
> Amos Kong <akong@redhat.com> writes:
> > From: Rusty Russell <rusty@rustcorp.com.au>
> >
> > The previous patch added one potential problem: we can still be
> > reading from a hwrng when it's unregistered. Add a wait for zero
> > in the hwrng_unregister path.
> >
> > v4: add cleanup_done flag to insure that cleanup is done
>
> That's a bit weird. The usual pattern would be to hold a reference
> until we're actually finished, but this reference is a bit weird.
The cleanup function is a callback function of kref_put(), we can't
use the same reference count inside cleanup function.
> We hold the mutex across cleanup, so we could grab that but we have to
> take care sleeping inside wait_event, otherwise Peter will have to fix
> my code again :)
We didn't hold rng_mutex inside cleanup_rng(), am I missing something?
> AFAICT the wake_woken() stuff isn't merged yet, so your patch will
> have to do for now.
Can you provide some patches/mail link here? I searched nothing about wake_woken.
> > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
> >
> > if (rng->cleanup)
> > rng->cleanup(rng);
> > + rng->cleanup_done = true;
> > + wake_up_all(&rng_done);
> > }
> >
> > static void set_current_rng(struct hwrng *rng)
> > @@ -536,6 +539,11 @@ void hwrng_unregister(struct hwrng *rng)
> > kthread_stop(hwrng_fill);
> > } else
> > mutex_unlock(&rng_mutex);
> > +
> > + /* Just in case rng is reading right now, wait. */
> > + wait_event(rng_done, rng->cleanup_done &&
> > + atomic_read(&rng->ref.refcount) == 0);
> > +
>
> The atomic_read() isn't necessary here.
>
> However, you should probably init cleanup_done in hwrng_register().
> (Probably noone does unregister then register, but let's be clear).
Got it.
> Thanks,
> Rusty.
>
> > }
> > EXPORT_SYMBOL_GPL(hwrng_unregister);
> >
> > diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
> > index c212e71..7832e50 100644
> > --- a/include/linux/hw_random.h
> > +++ b/include/linux/hw_random.h
> > @@ -46,6 +46,7 @@ struct hwrng {
> > /* internal. */
> > struct list_head list;
> > struct kref ref;
> > + bool cleanup_done;
> > };
> >
> > /** Register a new Hardware Random Number Generator driver. */
> > --
> > 1.9.3
--
Amos.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Amos Kong <akong@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
herbert@gondor.apana.org.au, m@bues.ch, mb@bu3sch.de,
mpm@selenic.com, amit.shah@redhat.com,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v4 4/6] hw_random: fix unregister race.
Date: Tue, 25 Nov 2014 15:42:23 +0800 [thread overview]
Message-ID: <20141125074223.GA11690@air.redhat.com> (raw)
In-Reply-To: <87y4rhm5fv.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]
On Wed, Nov 12, 2014 at 02:33:00PM +1030, Rusty Russell wrote:
> Amos Kong <akong@redhat.com> writes:
> > From: Rusty Russell <rusty@rustcorp.com.au>
> >
> > The previous patch added one potential problem: we can still be
> > reading from a hwrng when it's unregistered. Add a wait for zero
> > in the hwrng_unregister path.
> >
> > v4: add cleanup_done flag to insure that cleanup is done
>
> That's a bit weird. The usual pattern would be to hold a reference
> until we're actually finished, but this reference is a bit weird.
The cleanup function is a callback function of kref_put(), we can't
use the same reference count inside cleanup function.
> We hold the mutex across cleanup, so we could grab that but we have to
> take care sleeping inside wait_event, otherwise Peter will have to fix
> my code again :)
We didn't hold rng_mutex inside cleanup_rng(), am I missing something?
> AFAICT the wake_woken() stuff isn't merged yet, so your patch will
> have to do for now.
Can you provide some patches/mail link here? I searched nothing about wake_woken.
> > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
> >
> > if (rng->cleanup)
> > rng->cleanup(rng);
> > + rng->cleanup_done = true;
> > + wake_up_all(&rng_done);
> > }
> >
> > static void set_current_rng(struct hwrng *rng)
> > @@ -536,6 +539,11 @@ void hwrng_unregister(struct hwrng *rng)
> > kthread_stop(hwrng_fill);
> > } else
> > mutex_unlock(&rng_mutex);
> > +
> > + /* Just in case rng is reading right now, wait. */
> > + wait_event(rng_done, rng->cleanup_done &&
> > + atomic_read(&rng->ref.refcount) == 0);
> > +
>
> The atomic_read() isn't necessary here.
>
> However, you should probably init cleanup_done in hwrng_register().
> (Probably noone does unregister then register, but let's be clear).
Got it.
> Thanks,
> Rusty.
>
> > }
> > EXPORT_SYMBOL_GPL(hwrng_unregister);
> >
> > diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
> > index c212e71..7832e50 100644
> > --- a/include/linux/hw_random.h
> > +++ b/include/linux/hw_random.h
> > @@ -46,6 +46,7 @@ struct hwrng {
> > /* internal. */
> > struct list_head list;
> > struct kref ref;
> > + bool cleanup_done;
> > };
> >
> > /** Register a new Hardware Random Number Generator driver. */
> > --
> > 1.9.3
--
Amos.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-11-25 7:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 15:56 [PATCH v4 0/6] fix hw_random stuck Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-03 15:56 ` [PATCH v4 1/6] hw_random: place mutex around read functions and buffers Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-03 15:56 ` [PATCH v4 2/6] hw_random: move some code out mutex_lock for avoiding underlying deadlock Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-03 15:56 ` [PATCH v4 3/6] hw_random: use reference counts on each struct hwrng Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-12 3:41 ` Rusty Russell
2014-11-12 3:41 ` Rusty Russell
2014-11-17 15:20 ` Amos Kong
2014-11-17 15:20 ` Amos Kong
2014-11-03 15:56 ` [PATCH v4 4/6] hw_random: fix unregister race Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-10 13:47 ` Herbert Xu
2014-11-10 13:47 ` Herbert Xu
2014-11-12 4:47 ` Herbert Xu
2014-11-12 4:47 ` Herbert Xu
2014-11-12 4:03 ` Rusty Russell
2014-11-25 7:42 ` Amos Kong [this message]
2014-11-25 7:42 ` Amos Kong
2014-12-06 3:51 ` Amos Kong
2014-12-06 3:51 ` Amos Kong
2014-11-12 4:03 ` Rusty Russell
2014-11-03 15:56 ` [PATCH v4 5/6] hw_random: don't double-check old_rng Amos Kong
2014-11-03 15:56 ` Amos Kong
2014-11-03 15:56 ` [PATCH v4 6/6] hw_random: don't init list element we're about to add to list Amos Kong
2014-11-03 15:56 ` Amos Kong
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=20141125074223.GA11690@air.redhat.com \
--to=akong@redhat.com \
--cc=amit.shah@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m@bues.ch \
--cc=mb@bu3sch.de \
--cc=mpm@selenic.com \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/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.