Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 27 Nov 2017 21:29:26 -0800 | Subject | Re: [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.
| |