linux-kernel - Re: [tip:sched/urgent] sched: Fix cross-cpu clock sync on remote wakeups

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:	Fri, 03 Jun 2011 12:36:00 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Milton Miller <miltonm@....com>
Cc:	Yong Zhang <yong.zhang0@...il.com>, Borislav Petkov <bp@...64.org>,
	Borislav Petkov <bp@...en8.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"markus@...ppelsdorf.de" <markus@...ppelsdorf.de>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:sched/urgent] sched: Fix cross-cpu clock sync on remote
 wakeups

On Fri, 2011-06-03 at 04:57 -0500, Milton Miller wrote:

> [me looks closely at patch and finds early return]

Yeah, in case there's nothing to do, all the old conditions hold and
irq_enter isn't strictly required.

> > 
> > We could of course add it in sched.c since the logic recurses just
> > fine.. its not pretty though.. :/
> > 
> > Thoughts?
> 
> 
> Many architectures already have an irq_enter becuase they have a single
> interrupt to the cpu for all external causes including software; they
> do the irq_enter before reading from the irq controller to know the
> reason for the interrupt.  A quick glance at irq_enter and irq_exit
> shows they will do several things twice when nested, even if that
> is safe.

Agreed, and its a worry I had. The flip side is that doing it in the
arch code means I have to audit all the archs again (not that I mind too
much, but it takes a wee bit longer), also I'll have to look at all the
code using this IPI for the old purpose.

> Are there really that many calls with the empty list that it makes
> sense to avoid and optimize this on x86 while penalizing the several
> architectures with a nested irq_enter and exit?

I _think_ the now predominant case is this remote wakeup, so adding
irq_enter() to all arch paths isn't too big of a problem, but I need to
make sure.

>   When it also duplicates
> sched_ttwu_pending (because it can't be common with the additional tests)?

yeah, sad that.

> We said the perf mon callback (now irq_work) had to be under irq_enter.

Correct, anything that actually does something in the handler needs
irq_enter, the problem with the resched ipi was that it never actually
did anything and the idle loop exit took care of the no_hz funnies.

> Can we get some numbers for how often the two cases occur on some
> various workloads?

Sure, let me stick some counters in.
--
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/