All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	jiangshanlai@gmail.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
	dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com,
	oleg@redhat.com, Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will.deacon@arm.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Andrea Parri <parri.andrea@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair
Date: Thu, 17 Aug 2017 08:07:36 -0700	[thread overview]
Message-ID: <20170817150736.GQ7017@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170816112235.3acc59f2@gandalf.local.home>

On Wed, Aug 16, 2017 at 11:22:35AM -0400, Steven Rostedt wrote:
> On Tue, 15 Aug 2017 09:16:29 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair.  This commit therefore replaces the spin_unlock_wait() call in
> > completion_done() with spin_lock() followed immediately by spin_unlock().
> > This should be safe from a performance perspective because the lock
> > will be held only the wakeup happens really quickly.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Andrea Parri <parri.andrea@gmail.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > [ paulmck: Updated to use irqsave based on 0day Test Robot feedback. ]
> > 
> > diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
> > index 13fc5ae9bf2f..c9524d2d9316 100644
> > --- a/kernel/sched/completion.c
> > +++ b/kernel/sched/completion.c
> > @@ -300,6 +300,8 @@ EXPORT_SYMBOL(try_wait_for_completion);
> >   */
> >  bool completion_done(struct completion *x)
> >  {
> > +	unsigned long flags;
> > +
> >  	if (!READ_ONCE(x->done))
> >  		return false;
> >  
> > @@ -307,14 +309,9 @@ bool completion_done(struct completion *x)
> >  	 * If ->done, we need to wait for complete() to release ->wait.lock
> >  	 * otherwise we can end up freeing the completion before complete()
> >  	 * is done referencing it.
> > -	 *
> > -	 * The RMB pairs with complete()'s RELEASE of ->wait.lock and orders
> > -	 * the loads of ->done and ->wait.lock such that we cannot observe
> > -	 * the lock before complete() acquires it while observing the ->done
> > -	 * after it's acquired the lock.
> >  	 */
> > -	smp_rmb();
> > -	spin_unlock_wait(&x->wait.lock);
> > +	spin_lock_irqsave(&x->wait.lock, flags);
> > +	spin_unlock_irqrestore(&x->wait.lock, flags);
> >  	return true;
> >  }
> >  EXPORT_SYMBOL(completion_done);
> 
> For this patch:
> 
> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Applied, thank you!

> But I was looking at this function, and it is a little worrisome, as it
> says it should return false if there are waiters and true otherwise.
> But it can also return false if there are no waiters and the completion
> is already done.
> 
> Basically we have:
> 
> 	wait_for_completion() {
> 		while (!done)
> 			wait();
> 		done--;
> 	}
> 
> 	complete() {
> 		done++;
> 		wake_up_waiters();
> 	}
> 
> Thus, completion_done() only returns true if a complete happened and a
> wait_for_completion has not. It does not return true if the complete
> has not yet occurred, but there are still waiters.
> 
> I looked at a couple of use cases, and this does not appear to be an
> issue, but the documentation about the completion_done() does not
> exactly fit the implementation. Should that be addressed?
> 
> Also, if complete_all() is called, then reinit_completion() must be
> called before that completion is used. The reinit_completion() has a
> comment stating this, but there's no comment by complete_all() stating
> this, which is where it really should be. I'll send a patch to fix this
> one.

But I am too late to return the favor -- good patch, though!

							Thanx, Paul

  reply	other threads:[~2017-08-17 15:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 22:12 [PATCH tip/core/rcu 0/9] Remove spin_unlock_wait() Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock() Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 2/9] task_work: Replace spin_unlock_wait() with lock/unlock pair Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 3/9] sched: " Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 4/9] completion: " Paul E. McKenney
2017-08-15 16:16   ` [PATCH v5 " Paul E. McKenney
2017-08-16 15:22     ` Steven Rostedt
2017-08-17 15:07       ` Paul E. McKenney [this message]
2017-08-17  8:26     ` Ingo Molnar
2017-08-17 12:30       ` Paul E. McKenney
2017-08-17 12:49         ` Ingo Molnar
2017-08-17 14:13           ` Paul E. McKenney
2017-08-17 15:32             ` Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 5/9] exit: " Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 6/9] ipc: " Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 7/9] drivers/ata: " Paul E. McKenney
2017-07-24 22:13   ` Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 8/9] locking: Remove spin_unlock_wait() generic definitions Paul E. McKenney
2017-07-24 22:13 ` [PATCH tip/core/rcu 9/9] arch: Remove spin_unlock_wait() arch-specific definitions Paul E. McKenney
2017-07-24 22:13   ` Paul E. McKenney
2017-07-31 22:57 ` [PATCH v2 tip/core/rcu 0/10] Remove spin_unlock_wait() Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 01/10] atomics: Revert addition of comment header to spin_unlock_wait() Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 02/10] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock() Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 03/10] task_work: Replace spin_unlock_wait() with lock/unlock pair Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 04/10] sched: " Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 05/10] completion: " Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 06/10] exit: " Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 07/10] ipc: " Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 08/10] drivers/ata: " Paul E. McKenney
2017-07-31 22:58     ` Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 09/10] locking: Remove spin_unlock_wait() generic definitions Paul E. McKenney
2017-07-31 22:58   ` [PATCH v2 tip/core/rcu 10/10] arch: Remove spin_unlock_wait() arch-specific definitions Paul E. McKenney
2017-07-31 22:58     ` Paul E. McKenney

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=20170817150736.GQ7017@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=parri.andrea@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.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.