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: <4549D0D2.6050309@vmware.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ