lkml.org 
[lkml]   [2017]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 11/21] x86/dumpstack: Handle stack overflow on all stacks
On Mon, Nov 27, 2017 at 8:29 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Mon, Nov 27, 2017 at 11:26:30AM -0800, Linus Torvalds wrote:
>> On Mon, Nov 27, 2017 at 2:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> > From: Andy Lutomirski <luto@kernel.org>
>> >
>> > We currently special-case stack overflow on the task stack. We're
>> > going to start putting special stacks in the fixmap with a custom
>> > layout, so they'll have guard pages, too. Teach the unwinder to be
>> > able to unwind an overflow of any of the stacks.
>>
>> Why isn't this together with 01/21? The two cases seem to be entirely
>> identical and fundamentally the same issue.
>
> Yeah, they probably do belong in the same patch.
>
>> In fact, maybe the whole "stack overflow" special cases should be in
>> "get_stack_info()" itself, rather than be special-cased in the
>> callers?
>
> I would be nervous about doing that. Several of the get_stack_info()
> callers rely on it being honest.
>
> In fact, looking deeper at the above patch, it doesn't seem convincingly
> safe to me. What if the adjacent page doesn't exist? Then when the
> oops dumping code dereferences the 'stack' variable, you get an oops in
> your oops.
>

Isn't the oops dumping code supposed to dereference everything using a
special safe function?

Anyway, get_stack_info() wouldn't really be lying. It would just be
returning something where begin..end doesn't contain the requested
pointer.

\
 
 \ /
  Last update: 2017-11-28 06:31    [W:0.055 / U:2.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site