All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	computersforpeace@gmail.com, Ingo Molnar <mingo@kernel.org>,
	der.herr@hofr.at
Subject: Re: complete_all and "forever" completions
Date: Wed, 26 Oct 2016 17:42:13 +0200	[thread overview]
Message-ID: <20161026154213.GD3117@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20161026121001.GA19692@dtor-ws>

On Wed, Oct 26, 2016 at 05:10:01AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote:

> > > Or do we need something like this in
> > > do_wait_for_common():
> > > 
> > > 	if (x->done < UINT_MAX/2)
> > > 		x->done--;
> > 
> > Depends a bit, do you really want this? Seems a bit daft to keep asking
> > if its done already, seems like a waste of cycles to me.
> > 
> 
> The use case I am after is:
> 
> 1. There is a device that is extremely dumb without firmware
> 2. The driver uses request_firmware_nowait() and signals completion from
> the firmware loading callback to let the reset of the driver know that
> firmware has been done loading (successfully or otherwise)
> 3. The driver uses wait_for_completion() in both remove() and suspend()
> methods to wait for the firmware to finish loading.
> 
> While remove() happens at most once per device instance, suspend() may
> happen unbound number of times (theoretically).
> 
> So the question is: should complete_all have this "forever" semantic
> (IOW is documentation right about the intent) or do we need a new
> primitive for this? From the cursory glance of users of complete_all()
> all of them expect completion to stay in signalled state either forever,
> or until they call reinit_completion() explicitly.

Nah, if we need this we should fix this one. Adding similar but slightly
different primitives is a pain.

But I think you might need slightly more than the proposed change, the
case I worry about is doing complete_all() when done != 0 (which isn't
all that strange).


Does something like so work?

---
 kernel/sched/completion.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 8d0f35debf35..5deab9c789df 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -51,7 +51,7 @@ void complete_all(struct completion *x)
 	unsigned long flags;
 
 	spin_lock_irqsave(&x->wait.lock, flags);
-	x->done += UINT_MAX/2;
+	x->done = UINT_MAX/2;
 	__wake_up_locked(&x->wait, TASK_NORMAL, 0);
 	spin_unlock_irqrestore(&x->wait.lock, flags);
 }
@@ -79,7 +79,10 @@ do_wait_for_common(struct completion *x,
 		if (!x->done)
 			return timeout;
 	}
-	x->done--;
+
+	if (x->done != UINT_MAX/2)
+		x->done--;
+
 	return timeout ?: 1;
 }
 

  reply	other threads:[~2016-10-26 15:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 22:30 complete_all and "forever" completions Dmitry Torokhov
2016-10-26  8:45 ` Peter Zijlstra
2016-10-26  9:15   ` Nicholas Mc Guire
2016-10-27  9:51     ` Daniel Wagner
2016-10-26 12:10   ` Dmitry Torokhov
2016-10-26 15:42     ` Peter Zijlstra [this message]
2016-10-26 15:46       ` Peter Zijlstra
2016-10-26 17:12       ` Nicholas Mc Guire
2016-10-26 17:20         ` Dmitry Torokhov
2016-10-26 18:23       ` Dmitry Torokhov

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=20161026154213.GD3117@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=computersforpeace@gmail.com \
    --cc=der.herr@hofr.at \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tj@kernel.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.