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, 20 Mar 2008 22:27:31 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Glauber Costa <gcosta@...hat.com>
cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tglx@...utronix.de, mingo@...e.hu, ak@...e.de
Subject: Re: [PATCH 45/79] [PATCH] fix apic acking of irqs

On Thu, 20 Mar 2008, Glauber Costa wrote:

> >  Are you sure this actually triggers for APIC chips affected by the erratum
> > in question?  And please note that for them the effect of two consecutive
> > writes will be much more disastrous than setting a bit in the ESR register.
> 
> I'm not _sure_, but I can't find anything in the errata list that states
> otherwise. It would be great that anyone has such a system to test it. But
> with the current conditions, it will break bootup code. In case it is really a
> problem, we'd need to make a special case for that.

 I have dug out the relevant erratum -- it is the 11AP one as referred to 
from arch/x86/kernel/smp_32.c and the text even mentions the EOI register 
explicitly:

"This problem affects systems that use HOLD/HLDA or BOFF# and enable the 
local APIC of the CPU.  If the second APIC write cycle is an EOI (End of 
Interrupt) cycle, the CPU will stop servicing subsequent interrupts of 
equal or less priority.  This may cause the system to hang.  If the second 
APIC write cycle is not an EOI, the failure mode would depend on the 
particular APIC register that is not updated correctly."

 But on this occasion I took the opportunity to refresh my memory on the 
ESR register and there is apparently no bit there, at least up to 
Pentium4, that would signify an error resulting from an incorrect access 
type -- only accesses to invalid register indices are marked as errors.  

 Which bit of the ESR can you see set as a result of using an RMW cycle to 
the EOI register and with what kind of CPU/APIC?  And why wouldn't it have 
affected older kernels? -- the error interrupt has been kept enabled by 
Linux for ages and writes to the EOI register are frequent enough it would 
be hard to miss the resulting flood of errors.  Hmm...

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