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
next prev parent reply other threads:[~2017-08-17 15:07 UTC|newest]
Thread overview: 29+ 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 ` [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-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 ` [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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox