linux-kernel - Re: [PATCH] sched: Buggy comparison in check_preempt

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]

Message-ID: <1293515293.6930.11.camel@marge.simson.net>
Date:	Tue, 28 Dec 2010 06:48:13 +0100
From:	Mike Galbraith <efault@....de>
To:	Venkatesh Pallipadi <venki@...gle.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, Ranjit Manomohan <ranjitm@...gle.com>
Subject: Re: [PATCH] sched: Buggy comparison in check_preempt_tick

On Sun, 2010-12-26 at 08:23 +0100, Mike Galbraith wrote:

> But anyway..
> 
> echo NO_WAKEUP_PREEMPT > sched_features
> echo NO_TESTME > sched_features
> two hogs running on isolcpu 3, pid 6890 at nice -2
> 
> while sleep 1; do  grep 'pert.*6890' /proc/sched_debug; done
> 
> runnable tasks:
>             task   PID         tree-key  switches  prio
> -------------------------------------------------------
> R           pert  6890     50201.071851      7453   118
> R           pert  6890     50596.171290      7513   118  +60
> R           pert  6890     50991.265264      7572   118  +59
> R           pert  6890     51383.781965      7631   118  +59
>             pert  6890     51781.463129      7691   118  +60
> 
> echo TESTME > sched_features
>             pert  6890    126881.306733     18977   118
> R           pert  6890    127273.825719     19036   118  +59
> R           pert  6890    127668.928218     19095   118  +59
> R           pert  6890    128064.031372     19154   118  +59
> R           pert  6890    128459.134339     19213   118  +59
> 
> ...with a compute load, the thing should be a noop, and appears to be so
> (with busted compare fixed anyway;).  You have to be well overloaded for
> buddies to kick in these days, so it's probably pretty hard to get
> enough spread for the thing to fire.

I did a bit more testing yesterday with wakeup loads.  There's enough
spread for the test to nudge things a few [0..4] times per second/core.

I'd either fix the comparison, and let it keep on nudging once in a
while, or whack the whole thing.

	-Mike

--
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/