linux-kernel - Re: [PATCH] sched: disable hrtick implementation

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] [day] [month] [year] [list]

Date:	Wed, 20 Aug 2008 11:43:25 -0700
From:	Justin Madru <jdm64@...ab.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Greg KH <gregkh@...e.de>, Ingo Molnar <mingo@...e.hu>,
	lkml <linux-kernel@...r.kernel.org>,
	Michal Januszewski <spock@...too.org>,
	Antonino Daplas <adaplas@...il.com>,
	Rafael Wysocki <rjw@...k.pl>,
	Romano Giannetti <romano.giannetti@...il.com>,
	Adrian Bunk <bunk@...nel.org>,
	Jeremy Nickurak <kernel-bugs@...us.rifetech.com>
Subject: Re: [PATCH] sched: disable hrtick implementation

Peter Zijlstra wrote:
> On Tue, 2008-08-19 at 15:54 -0700, Justin Madru wrote:
>> The hrtick implementation in 2.6.25 and .26 has been known to cause boot
>> problems with at least Intel GMA cards. see:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=15602
>> http://bugzilla.kernel.org/show_bug.cgi?id=10892
>>
>> A full fix to hrtick went into 2.6.27
>> (31656519e132f6612584815f128c83976a9aaaef),
>> but that fix is too intrusive to backport. Henceforth, we default to
>> disable hrtick.
>
> Thing is, I'm still not understanding how, or if, the old code is wrong.
>
> That said, this will paper over the problem just fine, and as its old
> kernels we're talking about I don't particularly care.

Fair enough.

All I know is that right when I started testing .25-rc1 I kept getting a 
garbled boot splash, blank screen, and even lock-ups during booting. It 
seemed to be that if I disabled the boot splash and/or started x 
manually the problem would rarely occur. So, maybe the first change to 
hrtick just exposed a bug in the boot splash or the x server. If that's 
true then, I don't get why right when .27-rc1 was out all the boot 
problems were gone.

Bisecting found both commits (introduce and fix) to be about hrtick. So 
maybe the commit that introduced my bug wasn't completely wrong, but at 
least it was not right enough because of the second commit was trying to 
fix something -- right? And the kernel still boots with hrtick disabled, 
I tested that.

> Just occured to me that a Kconfig change that always makes
> CONFIG_SCHED_HRTICK not set will also do.
>> Signed-off-by: Justin Madru <jdm64@...ab.com>
>> Tested-by: Justin Madru <jdm64@...ab.com>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Ingo Molnar <mingo@...e.hu>
>>
>> --- a/kernel/sched_features.h
>> +++ b/kernel/sched_features.h
>> @@ -4,7 +4,7 @@
>> SCHED_FEAT(AFFINE_WAKEUPS, 1)
>> SCHED_FEAT(CACHE_HOT_BUDDY, 1)
>> SCHED_FEAT(SYNC_WAKEUPS, 1)
>> -SCHED_FEAT(HRTICK, 1)
>> +SCHED_FEAT(HRTICK, 0)
>> SCHED_FEAT(DOUBLE_TICK, 0)
>> SCHED_FEAT(NORMALIZED_SLEEPER, 1)
>> SCHED_FEAT(DEADLINE, 1)
>>

Wouldn't disabling CONFIG_HIGH_RES_TIMERS (in the menu) also disable 
CONFIG_SCHED_HRTICK? In any case what about this patch below?

The hrtick implementation in 2.6.25 and .26 has been known to cause boot
problems with at least Intel GMA cards. see:

https://bugs.freedesktop.org/show_bug.cgi?id=15602
http://bugzilla.kernel.org/show_bug.cgi?id=10892

A full fix to hrtick went into 2.6.27 
(31656519e132f6612584815f128c83976a9aaaef),
but that fix is too intrusive to backport. Henceforth, we default to 
disable hrtick.

Signed-off-by: Justin Madru <jdm64@...ab.com>
Tested-by: Justin Madru <jdm64@...ab.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...e.hu>

--- a/kernel/Kconfig.hz
+++ b/kernel/Kconfig.hz
@@ -55,4 +55,5 @@
     default 1000 if HZ_1000

 config SCHED_HRTICK
-    def_bool HIGH_RES_TIMERS && X86
+    bool
+    default n

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