linux-kernel - Re: [RFC 3/6] x86, NMI, Rename memory parity error to PCI SERR error

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:	Wed, 22 Sep 2010 00:04:30 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Huang Ying <ying.huang@...el.com>
cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC 3/6] x86, NMI, Rename memory parity error to PCI SERR
 error

On Fri, 10 Sep 2010, Huang Ying wrote:

> memory parity error is only valid for IBM PC-AT, newer machine use 7
> bit (0x80) of 0x61 port for PCI SERR. While memory error is usually
> reported via MCE. So corresponding function name and kernel log string
> is changed.

 Things perhaps changed over the last few years while I have not been 
watching, but for many years the bit #7 of the NMI status port 
(implemented by the southbridge at 0x61 in the port I/O space) was still 
used for memory parity or ECC errors even after the original IBM PC/AT.  
The usual arrangement was in the event of a memory error the memory 
controller in the northbridge would assert the chip's PCI SERR output 
line, which in turn would be trapped by the southbridge and converted to 
an NMI event while setting the said bit in the NMI status port.  See e.g. 
the 82349HX System Controller datasheet (Intel document number 290551).

 So the name of the error reported is not that unjustified except, of 
course, to be precise the handler would have to scan the state of the SERR 
output reported by all the PCI devices in the PCI configuration space to 
find the originator and then interpret the event accordingly.  Which 
obviously means the only piece of code that could exactly know what the 
reason was is the respective device driver as causes of SERR are 
device-specific and may require processing of device-specific registers to 
determine the cause and/or recover (a device reset may be required in some 
cases).

 Of course using the MCE seems natural and better, especially if the 
exception can be raised synchronously and stop the failing memory load CPU 
instruction from completion -- this is important for parity and MBE ECC 
errors, where in some cases the handler may be able to retry the failing 
operation having refreshed RAM from the backing store or otherwise the 
affected process must be killed (unless a kernel memory location is 
involved that is, where the whole system has to be brought down).

 OTOH, for CPU stores and DMA transactions the event will always be 
asynchronous and an NMI might be a better option, as in the case of parity 
and MBE ECC errors the whole system will probably have to be brought down, 
and with SBE ECC errors scrubbing can be done at any time and otherwise 
(except from logging and/or marking the physical page bad, as required) no 
action is needed.

  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/