summaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/check.c
Commit message (Collapse)AuthorAgeFilesLines
* x86: fix 64k corruption-checkYinghai Lu2009-03-151-3/+3
| | | | | | | | | | | | | | | Impact: fix boot crash Need to exit early if the addr is far above 64k. The crash got exposed by: 78a8b35: x86: make e820_update_range() handle small range update Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: <stable@kernel.org> LKML-Reference: <49BC2279.2030101@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: fix code paths used by update_mptableJan Beulich2009-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Impact: fix crashes under Xen due to unrobust e820 code find_e820_area_size() must return a properly distinguishable and out-of-bounds value when it fails, and -1UL does not meet that criteria on i386/PAE. Additionally, callers of the function must check against that value. early_reserve_e820() should be prepared for the region found to be outside of the addressable range on 32-bits. e820_update_range_map() should not blindly update e820, but should do all it work on the map it got a pointer passed for (which in 50% of the cases is &e820_saved). It must also not call e820_add_region(), as that again acts on e820 unconditionally. The issues were found when trying to make this option work in our Xen kernel (i.e. where some of the silent assumptions made in the code would not hold). Signed-off-by: Jan Beulich <jbeulich@novell.com> LKML-Reference: <49B9171B.76E4.0078.0@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: corruption-check: some post-move cleanupsArjan van de Ven2008-10-271-8/+4
| | | | | | | | | | Impact: cleanup now that the code is moved and converted to a work queue, there's some minor cleanups that can be done. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: corruption check: run the corruption checks from a work queueArjan van de Ven2008-10-271-10/+17
| | | | | | | | | | | Impact: change the implementation of the debug feature the periodic corruption checks are better off run from a work queue; there's nothing time critical about them and this way the amount of interrupt-context work is reduced. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: corruption check: move the corruption checks into their own fileArjan van de Ven2008-10-271-0/+158
Impact: cleanup The corruption check code is rather sizable and it's likely to grow over time when we add checks for more types of corruptions (there's a few candidates in kerneloops.org that I want to add checks for)... so lets move it to its own file Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
OpenPOWER on IntegriCloud