coreboot-kgpe-d16/src/lib/stack.c

61 lines
2.2 KiB
C
Raw Normal View History

/*
This software and ancillary information (herein called SOFTWARE )
called LinuxBIOS is made available under the terms described
here. The SOFTWARE has been approved for release with associated
LA-CC Number 00-34 . Unless otherwise indicated, this SOFTWARE has
been authored by an employee or employees of the University of
California, operator of the Los Alamos National Laboratory under
Contract No. W-7405-ENG-36 with the U.S. Department of Energy. The
U.S. Government has rights to use, reproduce, and distribute this
SOFTWARE. The public may copy, distribute, prepare derivative works
and publicly display this SOFTWARE without charge, provided that this
Notice and any statement of authorship are reproduced on all copies.
Neither the Government nor the University makes any warranty, express
or implied, or assumes any liability or responsibility for the use of
this SOFTWARE. If SOFTWARE is modified to produce derivative works,
such modified SOFTWARE should be clearly marked, so as not to confuse
it with the version available from LANL.
*/
/* Copyright 2000, Ron Minnich, Advanced Computing Lab, LANL
* rminnich@lanl.gov
* Copyright (C) 2015 Timothy Pearson <tpearson@raptorengineeringinc.com>,
* Raptor Engineering
*/
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
#include <assert.h>
#include <lib.h>
#include <console/console.h>
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
#include <symbols.h>
int checkstack(void *top_of_stack, int core)
{
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
/* Not all archs use CONFIG_STACK_SIZE, those who don't set it to 0. */
size_t stack_size = CONFIG_STACK_SIZE ? CONFIG_STACK_SIZE : _stack_size;
int i;
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
u32 *stack = (u32 *) (top_of_stack - stack_size);
src/lib: Fix spacing Fix the following errors and warnings detected by checkpatch.pl: ERROR: spaces required around that '?' (ctx:WxV) ERROR: spaces required around that '=' (ctx:VxV) ERROR: spaces required around that '<' (ctx:VxV) ERROR: spaces required around that '+=' (ctx:VxV) ERROR: space required after that ',' (ctx:VxV) ERROR: space required before the open brace '{' ERROR: space required after that close brace '}' ERROR: need consistent spacing around '+' (ctx:WxV) ERROR: need consistent spacing around '*' (ctx:WxV) ERROR: need consistent spacing around '&' (ctx:VxW) ERROR: spaces required around that '?' (ctx:VxW) ERROR: spaces required around that ':' (ctx:VxW) ERROR: trailing whitespace ERROR: space prohibited before that '++' (ctx:WxO) ERROR: space prohibited before that ',' (ctx:WxW) ERROR: space prohibited after that '!' (ctx:BxW) ERROR: spaces prohibited around that '->' (ctx:VxW) ERROR: space prohibited after that '-' (ctx:WxW) WARNING: space prohibited before semicolon WARNING: unnecessary whitespace before a quoted newline WARNING: missing space after return type Note that lib/libgcov.c and lib/lzmadecode.c are providing false positives for ERROR: need consistent spacing around '*' (ctx:WxV) An example is: void __gcov_merge_add(gcov_type *counters __attribute__ ((unused)), unsigned int n_counters __attribute__ ((unused))) {} TEST=Build and run on Galileo Gen2 Change-Id: I0016327a5754018eaeb25bedf42338291632c7c1 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18733 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-10 02:35:28 +01:00
if (stack[0] != 0xDEADBEEF) {
printk(BIOS_ERR,
"Stack overrun on CPU%d (address %p overwritten). "
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
"Increase stack from current %zu bytes\n",
core, stack, stack_size);
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
BUG();
return -1;
}
src/lib: Fix spacing Fix the following errors and warnings detected by checkpatch.pl: ERROR: spaces required around that '?' (ctx:WxV) ERROR: spaces required around that '=' (ctx:VxV) ERROR: spaces required around that '<' (ctx:VxV) ERROR: spaces required around that '+=' (ctx:VxV) ERROR: space required after that ',' (ctx:VxV) ERROR: space required before the open brace '{' ERROR: space required after that close brace '}' ERROR: need consistent spacing around '+' (ctx:WxV) ERROR: need consistent spacing around '*' (ctx:WxV) ERROR: need consistent spacing around '&' (ctx:VxW) ERROR: spaces required around that '?' (ctx:VxW) ERROR: spaces required around that ':' (ctx:VxW) ERROR: trailing whitespace ERROR: space prohibited before that '++' (ctx:WxO) ERROR: space prohibited before that ',' (ctx:WxW) ERROR: space prohibited after that '!' (ctx:BxW) ERROR: spaces prohibited around that '->' (ctx:VxW) ERROR: space prohibited after that '-' (ctx:WxW) WARNING: space prohibited before semicolon WARNING: unnecessary whitespace before a quoted newline WARNING: missing space after return type Note that lib/libgcov.c and lib/lzmadecode.c are providing false positives for ERROR: need consistent spacing around '*' (ctx:WxV) An example is: void __gcov_merge_add(gcov_type *counters __attribute__ ((unused)), unsigned int n_counters __attribute__ ((unused))) {} TEST=Build and run on Galileo Gen2 Change-Id: I0016327a5754018eaeb25bedf42338291632c7c1 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18733 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-10 02:35:28 +01:00
for (i = 1; i < stack_size/sizeof(stack[0]); i++) {
if (stack[i] == 0xDEADBEEF)
continue;
printk(BIOS_SPEW, "CPU%d: stack: %p - %p, ",
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
core, stack, &stack[stack_size/sizeof(stack[0])]);
printk(BIOS_SPEW, "lowest used address %p, ", &stack[i]);
printk(BIOS_SPEW, "stack used: %ld bytes\n",
arm: Fix checkstack() to use correct stack size checkstack() runs at the end of ramstage to warn about stack overflows, and it assumes that CONFIG_STACK_SIZE is always the size of the stack to check. This is only true for systems that bring up multiprocessing in ramstage and assign a separate stack for each core, like x86 and ARM64. Other architectures like ARM and MIPS (for now) don't touch secondary CPUs at all and currently don't look like they'll ever need to, so they generally stay on the same (SRAM-based) stack they have been on since their bootblock. This patch tries to model that difference by making these architectures explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to assume the whole (_estack - _stack) area in checkstack() instead. Also adds a BUG() to the stack overflow check, since that is currently just as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM HALTED" output) but a little more easy to spot. Such a serious failure should not drown out in all the normal random pieces of lower case boot spam (also, I was intending to eventually have a look at assert() and BUG() to hopefully make them a little more useful/noticeable if I ever find the time for it). BRANCH=None BUG=None TEST=Booted Pinky, noticed it no longer complains about stack overflows. Built Falco, Ryu and Urara. Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4 Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/235894 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9610 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-16 03:19:03 +01:00
(unsigned long)&stack[stack_size / sizeof(stack[0])]
- (unsigned long)&stack[i]);
return 0;
}
return 0;
}