summaryrefslogtreecommitdiff
path: root/include/linux/i2c-ocores.h
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@sandeen.net>2008-04-22 16:38:23 -0500
committerThomas Gleixner <tglx@linutronix.de>2008-05-26 16:15:33 +0200
commit7c9f8861e6c9c839f913e49b98c3854daca18f27 (patch)
tree220b23dff1aa11a83546fbc73a319575ca489188 /include/linux/i2c-ocores.h
parentb40a4392a3c262e0d1b5379b4e142a8eefa63439 (diff)
stackprotector: use canary at end of stack to indicate overruns at oops time
(Updated with a common max-stack-used checker that knows about the canary, as suggested by Joe Perches) Use a canary at the end of the stack to clearly indicate at oops time whether the stack has ever overflowed. This is a very simple implementation with a couple of drawbacks: 1) a thread may legitimately use exactly up to the last word on the stack -- but the chances of doing this and then oopsing later seem slim 2) it's possible that the stack usage isn't dense enough that the canary location could get skipped over -- but the worst that happens is that we don't flag the overrun -- though this happens fairly often in my testing :( With the code in place, an intentionally-bloated stack oops might do: BUG: unable to handle kernel paging request at ffff8103f84cc680 IP: [<ffffffff810253df>] update_curr+0x9a/0xa8 PGD 8063 PUD 0 Thread overran stack or stack corrupted Oops: 0000 [1] SMP CPU 0 ... ... unless the stack overrun is so bad that it corrupts some other thread. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'include/linux/i2c-ocores.h')
0 files changed, 0 insertions, 0 deletions