linux-kernel - Re: [PATCH 4/7] Allow selected bug checks to be skipped by paravirt kernels

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, 02 Nov 2006 03:04:50 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Chris Wright <chrisw@...s-sol.org>, akpm@...l.org, ak@....de,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org
Subject: Re: [PATCH 4/7] Allow selected bug checks to be skipped by paravirt
 kernels

Pavel Machek wrote:
>>> How can hlt check break? It is hlt;hlt;hlt, IIRC, that looks fairly
>>> innocent to me.
>>>  
>>>       
>> Not if you use tickless timers that don't generate interrupts to unhalt 
>> you, or if you delay ticks until the next scheduled timeout and you 
>> haven't yet scheduled any timeout.  Both are likely in a hypervisor.
>>     
>
> Well.. but you are working around problem, instead of fixing it.
>
> Tickless kernels are possible on normal machines, too.
>
> Please fix it properly... probably by requesting timer 10msec in
> advance or something.
> 									Pavel
>   

Well, I agree in spirit, but there is something to be said for keeping 
the code less complicated by removing these workarounds for broken 
processors.  Preferably, we could remove the hlt check entirely, but 
then those people with these broken processors would not get the 
expected behavior of stalling during boot - that is the expected 
behavior of failure, correct?  In any case, I added this workaround for 
the case when running under Xen.  I would rather not add a dependence on 
timer scheduling to legacy bug checking code when the number of timer 
sources and tickless variations available is proliferating and the 
number of legacy processors that would even need this check is rapidly 
approaching zero.

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