All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amos Kong <akong@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: herbert@gondor.apana.org.au, kvm@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, m@bues.ch,
	mpm@selenic.com, amit.shah@redhat.com
Subject: Re: [PATCH v4 4/6] hw_random: fix unregister race.
Date: Sat, 6 Dec 2014 11:51:16 +0800	[thread overview]
Message-ID: <20141206035116.GA1995@air.redhat.com> (raw)
In-Reply-To: <87y4rhm5fv.fsf@rustcorp.com.au>


[-- Attachment #1.1: Type: text/plain, Size: 1810 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.
> 
> 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 :)
> 
> AFAICT the wake_woken() stuff isn't merged yet, so your patch will
> have to do for now.
> 
> > @@ -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.

At least, we need it to convert refcount from atomic_t to int.
Otherwise, we will touch this error:

  error: invalid operands to binary == (have 'atomic_t' and 'int')
 
> However, you should probably init cleanup_done in hwrng_register().
> (Probably noone does unregister then register, but let's be clear).
> 
> Thanks,
> Rusty.

-- 
			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, 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: Sat, 6 Dec 2014 11:51:16 +0800	[thread overview]
Message-ID: <20141206035116.GA1995@air.redhat.com> (raw)
In-Reply-To: <87y4rhm5fv.fsf@rustcorp.com.au>

[-- Attachment #1: Type: text/plain, Size: 1810 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.
> 
> 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 :)
> 
> AFAICT the wake_woken() stuff isn't merged yet, so your patch will
> have to do for now.
> 
> > @@ -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.

At least, we need it to convert refcount from atomic_t to int.
Otherwise, we will touch this error:

  error: invalid operands to binary == (have 'atomic_t' and 'int')
 
> However, you should probably init cleanup_done in hwrng_register().
> (Probably noone does unregister then register, but let's be clear).
> 
> Thanks,
> Rusty.

-- 
			Amos.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-12-06  3:51 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-12  4:03   ` Rusty Russell
2014-11-25  7:42     ` Amos Kong
2014-11-25  7:42       ` Amos Kong
2014-12-06  3:51     ` Amos Kong [this message]
2014-12-06  3:51       ` Amos Kong
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=20141206035116.GA1995@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=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.