linux-kernel - Re: [PATCH] sched: update_rq_clock() must skip ONE update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 Apr 2014 10:02:18 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched: update_rq_clock() must skip ONE update

On Tue, 2014-04-01 at 11:55 +0200, Ingo Molnar wrote: 
> * Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> 
> > On Mon, 2014-03-31 at 11:37 -0700, Linus Torvalds wrote: 
> > > On Mon, Mar 31, 2014 at 11:27 AM, Mike Galbraith
> > > <umgwanakikbuti@...il.com> wrote:
> > > >
> > > > Oh, I didn't cc you because I wanted it applied instantly as ultra
> > > > critical, only because the chain of events might be of interest.
> > > 
> > > Ok. That was my main worry, since I was in the process or releasing
> > > 3.14, and I just couldn't tell if the patch was something I should
> > > worry about or not.
> > > 
> > > And it seems that not applying it was the right thing, which is all
> > > that matters by now.
> > 
> > Yes.  Jocular red flag was to Peter and Ingo.  I don't try to bypass 
> > them, that would be plain rude.  I've been known to help maintainers 
> > a little, but I don't ever try to call the shots.  They do that 
> > well.
> 
> Btw., in general feel free to Cc: Linus if a fix looks truly urgent, 
> as neither Peter nor me might be around on a weekend, shortly before a 
> release.

Still not urgent, but now verified to have fixed the large IO beast boot
problem.  'course that implies that disk discovery may generate truly
magnificent wakeup latency.. for the throttle to helpfully double.

---cut here---

Prevent large wakeup latencies from being accounted to the wrong task.

Cc: <stable@...r.kernel.org>
Signed-off-by: 	Mike Galbraith <umgwanakikbuti@...il.com>
---
 kernel/sched/core.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -118,7 +118,12 @@ void update_rq_clock(struct rq *rq)
 {
 	s64 delta;
 
-	if (rq->skip_clock_update > 0)
+	/*
+	 * Set during wakeup to indicate we are on the way to schedule().
+	 * Decrement to ensure that a very large latency is not accounted
+	 * to the wrong task.
+	 */
+	if (rq->skip_clock_update-- > 0)
 		return;
 
 	delta = sched_clock_cpu(cpu_of(rq)) - rq->clock;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/