Re: [PATCH 2/2] sched: BUG when stack end location is over written
From: Peter Zijlstra <peterz@infradead.org>
Date: 2014-09-04 15:32:51
Also in:
lkml
On Thu, Sep 04, 2014 at 03:50:24PM +0100, Aaron Tomlin wrote:
quoted hunk ↗ jump to hunk
Currently in the event of a stack overrun a call to schedule() does not check for this type of corruption. This corruption is often silent and can go unnoticed. However once the corrupted region is examined at a later stage, the outcome is undefined and often results in a sporadic page fault which cannot be handled. This patch checks for a stack overrun and takes appropriate action since the damage is already done, there is no point in continuing. Signed-off-by: Aaron Tomlin <redacted> --- kernel/sched/core.c | 3 +++ 1 file changed, 3 insertions(+)diff --git a/kernel/sched/core.c b/kernel/sched/core.c index ec1a286..d6af6a0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c@@ -2660,6 +2660,9 @@ static noinline void __schedule_bug(struct task_struct *prev) */ static inline void schedule_debug(struct task_struct *prev) { + if (unlikely(prev != &init_task && + task_stack_end_corrupted(prev))) + BUG();
superfluous linebreak, also we appear to have BUG_ON() for situations just like these. secondly, while I appreciate the 'feature' you're making schedule() slower for everybody, what do you propose to do about that?